1. はじめに

このガイドでは、Keycloakをアップグレードする方法について説明します。まずはKeycloakサーバーを、次にKeycloakアダプターをアップグレードすることをお勧めします。

アップグレードする前に、手順をよく読み移行に伴う変更内に示された変更を十分に確認してください。

2. Keycloakサーバーのアップグレード

2.1. アップグレードする準備

アップグレードする前に、踏まなければならない手順がありますので、その順序に気をつけてください。また、アップグレードする過程で起こり得る問題についても注意してください。通常は、まずKeycloakサーバーをアップグレードしてから、アダプターをアップグレードする必要があります。

  1. アップグレードする前に、開いているトランザクションを処理し、data/tx-object-store/トランザクション・ディレクトリーを削除します。

  2. 古いインストール(設定、テーマなど)をバックアップします。

  3. データベースをバックアップします。データベースのバックアップの仕方について、詳しくは、使用しているデータベースの関連ドキュメントを参照してください。

  4. Keycloakサーバーのアップグレード

    • プロダクション環境でインストールの問題に直面しないように、まずは非プロダクション環境でアップグレードのテストをすることがベスト・プラクティスです。

    • アップグレード後、データベースは古いサーバーとの互換性がなくなることに注意してください。

    • プロダクション環境でアダプターをアップグレードする前に、アップグレードしたサーバーが機能していることを確認してください。

  5. アップグレードを元に戻す必要がある場合は、まず古いインストールを復元してから、バックアップのコピーからデータベースを復元します。

  6. アダプターをアップグレードします。

2.2. Keycloakサーバーのアップグレード

アダプターをアップグレードする前に、Keycloakサーバーをアップグレードすることが重要です。

Keycloakサーバーをアップグレードするには、以下の手順に沿って行います。

  1. アップグレードする前に、開いているトランザクションを処理し、data/tx-object-store/トランザクション・ディレクトリーを削除します。

  2. 新しいサーバー・アーカイブをダウンロードします。

  3. ダウンロードしたアーカイブを移したい場所に移動させます。

  4. アーカイブを展開します。この手順により、最新のKeycloakのリリースのクリーンなインスタンスがインストールされます。

  5. スタンドアローン・モードでインストールするには、以前のインストールのKEYCLOAK_HOME/standalone/ディレクトリーを新しいインストールのディレクトリーにコピーします。

    ドメインモードでインストールするには、以前のインストールのKEYCLOAK_HOME/domain/ディレクトリーを新しいインストールのディレクトリーにコピーします。

    ドメインモードでインストールするには、空のKEYCLOAK_HOME/domain/deploymentsディレクトリーを作成します。

    binディレクトリー内のファイルを、以前のバージョンのファイルで上書してはいけません。変更は手作業で行う必要があります。
  6. modulesディレクトリーに追加されたカスタム・モジュールをコピーします。

  7. 以下の該当するアップグレード・スクリプトを実行します。

2.2.1. スタンドアローン・モード・アップグレード・スクリプトの実行

スタンドアローン・モード用のアップグレード・スクリプトを実行するには、以下の手順に従います。

  1. デフォルト以外の設定を使用している場合、移行スクリプトを編集して新しいファイル名を指定します。

  2. サーバーを停止します。

  3. アップグレード・スクリプトを実行します。

    bin/jboss-cli.sh --file=bin/migrate-standalone.cli

2.2.2. スタンドアローン-高可用性モードのアップグレード・スクリプトの実行

スタンドアローン-高可用性(HA)モードでは、インスタンスはすべて同時にアップグレードされる必要があります。

スタンドアローン-HAモードのアップグレード・スクリプトを実行するには、以下の手順に沿って行います。

  1. デフォルト以外の設定を使用している場合、移行スクリプトを編集して新しいファイル名を指定します。

  2. サーバーを停止します。

  3. アップグレード・スクリプトを実行します。

    bin/jboss-cli.sh --file=bin/migrate-standalone-ha.cli

2.2.3. ドメインモードのアップグレード・スクリプトの実行

ドメインモードでは、インスタンスはすべて同時にアップグレードされる必要があります。

ドメインモードでアップグレード・スクリプトを実行するには、以下の手順に沿って行います。

  1. プロファイル名を変更した場合、アップグレード・スクリプトを編集し、スクリプトの先頭付近の変数を変更する必要があります。

  2. keycloak-server.jsonファイルの場所を含むようにドメイン・スクリプトを編集します。

  3. サーバーを停止します。

  4. アップグレード・スクリプトをドメイン・コントローラー上でのみ実行します。

    bin/jboss-cli.sh --file=bin/migrate-domain.cli

2.2.4. ドメイン・クラスター・モード・アップグレード・スクリプトの実行

ドメイン・クラスター・モードでは、インスタンスはすべて同時にアップグレードされる必要があります。

ドメイン・クラスター・モードでアップグレード・スクリプトを実行するには、以下の手順に沿って行います。

  1. プロファイル名を変更した場合、アップグレード・スクリプトを編集し、スクリプトの先頭付近の変数を変更する必要があります。

  2. keycloak-server.jsonファイルの場所を含むようにドメイン・クラスター・スクリプトを編集します。

  3. サーバーを停止します。

  4. アップグレード・スクリプトをドメイン・コントローラー上でのみ実行します。

    bin/jboss-cli.sh --file=bin/migrate-domain-clustered.cli

2.3. データベース移行

Keycloakでは、データベース・スキーマの移行は自動的にできますが、手動でも行うことができます。デフォルトでは、初めての新規インストール時に、データベースは自動的に移行されます。

2.3.1. 自動リレーショナル・データベース移行

データベース・スキーマの自動アップグレードを有効にするには、デフォルトのconnectionsJpaプロバイダーのmigrationStrategyプロパティー値を"update"に設定します。

 <spi name="connectionsJpa">
    <provider name="default" enabled="true">
        <properties>
            ...
            <property name="migrationStrategy" value="update"/>
        </properties>
    </provider>
</spi>

または、このCLIコマンドを実行します。

/subsystem=keycloak-server/spi=connectionsJpa/provider=default/:map-put(name=properties,key=migrationStrategy,value=update)

データベース・スキーマが新バージョンに変更されていた場合、この設定でサーバーを起動すると、データベースは自動的に移行されます。

2.3.2. 手動リレーショナル・データベース移行

データベース・スキーマの手動アップグレードを有効にするには、デフォルトのconnectionsJpaプロバイダーのmigrationStrategyプロパティー値を"manual"に設定します。

 <spi name="connectionsJpa">
    <provider name="default" enabled="true">
        <properties>
            ...
            <property name="migrationStrategy" value="manual"/>
        </properties>
    </provider>
</spi>

または、このCLIコマンドを実行します。

/subsystem=keycloak-server/spi=connectionsJpa/provider=default/:map-put(name=properties,key=migrationStrategy,value=manual)

この設定でサーバーを起動すると、データベースを移行する必要があるかどうか確認されます。必要な変更はSQLファイルに書き込まれ、確認およびデータベースに対する手動実行が可能です。このファイルをデータベースに適用する方法についての詳細は、利用しているリレーショナル・データベース用のドキュメントを参照してください。ファイルに変更が書き込まれると、サーバーは終了します。

2.4. テーマの移行

カスタム・テーマを作成した場合、それらを新しいサーバーに移行する必要があります。組み込みのテーマの変更については、カスタマイズした項目に応じて、カスタム・テーマに反映させる必要があります。

古いサーバーの“themes”ディレクトリーから、新しいサーバーの“themes”ディレクトリーにカスタム・テーマをコピーする必要があります。その後、以下の変更を確認し、その変更をカスタム・テーマに適用させる必要があるかどうか検討しなければなりません。

要約すると、以下のとおりになります。

  • 以下に示した変更されたテンプレートをカスタマイズした場合、基本テーマのテンプレートと比較して、必要な変更があるかどうか確認しなければなりません。

  • スタイルをカスタマイズし、Keycloakテーマを拡張している場合、そのスタイルへの変更を確認する必要があります。基本テーマを拡張している場合は、この手順をスキップすることができます。

  • メッセージをカスタマイズした場合、キーまたは値を変更するか、メッセージを追加する必要があります。

2.4.1. テンプレートの移行

テンプレートをカスタマイズした場合、テンプレートに加えられた変更をしっかり確認し、カスタマイズしたテンプレートにそれらの変更を適用する必要があるかどうか判断しなければなりません。ほとんどの場合、カスタマイズしたテンプレートに同じ変更を適用する必要があります。テンプレートをカスタマイズしていなかった場合は、このセクションをスキップすることができます。

diffツールを使用してテンプレートを比較し、カスタマイズしたテンプレートにどんな変更を加えるか確認することがベスト・プラクティスになります。マイナーチェンジしただけの場合、更新したテンプレートとカスタマイズしたテンプレートを比較する方が簡単です。ただし、変更をたくさん加えた場合は、新しいテンプレートとカスタマイズした古いテンプレートを比較する方が、必要な変更が表示されるため簡単です。

下記のスクリーンショットは、ログイン・テーマのinfo.ftlテンプレートとサンプルのカスタム・テーマを比較しています。

更新版のログイン・テーマのテンプレートとサンプルのカスタム・ログイン・テーマのテンプレートの比較

theme migration meld info 1

この比較によって、1つ目の変更(“Hello world!!”)はカスタマイズで、2つ目の変更(“if pageRedirectUri”)は基本テーマの変更であるということが簡単に分かります。2つ目の変更をカスタム・テンプレートにコピーすると、カスタマイズしたテンプレートは正常に更新されます。

もう1つ代替の方法になりますが、下記のスクリーンショットは、古いインストールのinfo.ftlテンプレートと新しいインストールの更新版のinfo.ftlテンプレートを比較しています。

サンプルのカスタム・ログイン・テーマのテンプレートと更新版のログイン・テーマのテンプレートの比較

theme migration meld info 2

この比較によって、基本テンプレートにどんな変更が加えられたのか簡単に分かります。次に、変更したテンプレートに同じ変更を手動で加える必要があります。このアプローチは最初のほど簡単ではないため、最初のアプローチが実現不可能な場合にのみ、このアプローチを使用します。

2.4.2. メッセージの移行

別の言語のサポートを追加した場合、上記にリストした変更をすべて適用する必要があります。別の言語のサポートを追加していない場合は、何も変更する必要はありません。つまり、テーマが影響を受けるメッセージを変更した場合のみ、変更を加える必要があります。

追加した値については、基本テーマのメッセージの値を確認して、そのメッセージをカスタマイズする必要があるかどうかを判断します。

名前を変更したキーについては、カスタム・テーマのキーの名前も変更します。

変更した値については、基本テーマの値をチェックし、カスタム・テーマを変更する必要があるかどうか判断します。

2.4.3. スタイルの移行

keycloakまたはrh-ssoテーマからスタイルを引き継ぐ場合、カスタム・スタイルを更新し、組み込みテーマのスタイルに加えられた変更を反映させる必要があります。

diffツールを使用して、古いサーバー・インストールと新しいサーバー・インストールのスタイルシートの変更を比較することがベスト・プラクティスになります。

サンプルとして、下記のとおりdiffコマンドを使用します。

$ diff KEYCLOAK_HOME_OLD/themes/keycloak/login/resources/css/login.css \
KEYCLOAK_HOME_NEW/themes/keycloak/login/resources/css/login.css

変更を確認し、カスタム・スタイルに影響するかどうか判断します。

3. Keycloakアダプターのアップグレード

まずKeycloakサーバーをアップグレードし、次にアダプターをアップグレードすることが重要です。以前のバージョンのアダプターは、それ以降のバージョンのKeycloakサーバーで動作しますが、以前のバージョンのKeycloakサーバーは、それ以降のバージョンのアダプターでは動作しません。

3.1. Compatibility with older adapters

As mentioned above, we try to support newer release versions of Keycloak server working with older release versions of the adapters. However, in some cases we need to include fixes on the Keycloak server side which may break compatibility with older versions of the adapters. For example, when we implement new aspects of the OpenID Connect specification, which older client adapter versions were not aware of.

In those cases, we added Compatibility modes. For OpenId Connect clients, there is a section named OpenID Connect Compatibility Modes in the Keycloak admin console, on the page with client details. Here, you can disable some new aspects of the Keycloak server to preserve compatibility with older client adapters. More details are available in the tool tips of individual switches.

3.2. EAPアダプターのアップグレード

WildFlyアダプターをアップグレードするには、以下の手順に沿って行います。

  1. 新しいアダプター・アーカイブをダウンロードします。

  2. WILDFLY_HOME/modules/system/add-ons/keycloak/ ディレクトリーを削除することで、以前のアダプター・モジュールを削除します。

  3. ダウンロードしたアーカイブをWILDFLY_HOMEに解凍します。

3.3. Javaスクリプト・アダプターのアップグレード

webアプリケーションにコピーされたJavaスクリプト・アダプターをアップグレードするには、以下の手順に沿って行います。

  1. 新しいアダプター・アーカイブをダウンロードします。

  2. Overwrite the keycloak.js file in your application with the keycloak.js file from the downloaded archive.

3.4. Node.jsアダプターのアップグレード

webアプリケーションにコピーされたNode.jsアダプターをアップグレードするには、以下の手順に沿って行います。

  1. 新しいアダプター・アーカイブをダウンロードします。

  2. 既存のNode.jsアダプター・ディレクトリーを削除します。

  3. 更新されたファイルをその場所に解凍します。

  4. アプリケーションのpackage.json内のkeycloak-connectの依存関係を変更します。

4. 移行に伴う変更

4.1. Migrating to 4.0.0

4.1.1. Client Templates changed to Client Scopes

We added support for Client Scopes, which requires some attention during migration.

Client Templates changed to Client Scopes

Client Templates were changed to Client Scopes. If you had any Client Templates, their protocol mappers and role scope mappings will be preserved.

Spaces replaced in the names

Client templates with the space character in the name were renamed by replacing spaces with an underscore, because spaces are not allowed in the name of client scopes. For example, a client template my template will be changed to client scope my_template.

Linking Client Scopes to Clients

For clients which had the client template, the corresponding client scope is now added as Default Client Scope to the client. So protocol mappers and role scope mappings will be preserved on the client.

Realm Default Client Scopes not linked with existing clients

During the migration, the list of built-in client scopes is added to each realm as well as list of Realm Default Client Scopes. However, existing clients are NOT upgraded and new client scopes are NOT automatically added to them. Also all the protocol mappers and role scope mappings are kept on existing clients. In the new version, when you create a new client, it automatically has Realm Default Client Scopes attached to it and it does not have any protocol mappers attached to it. We did not change existing clients during migration as it would be impossible to properly detect customizations, which you will have for protocol mappers of the clients, for example. If you want to update existing clients (remove protocol mappers from them and link them with client scopes), you will need to do it manually.

Consents need to be confirmed again

The client scopes change required the refactoring of consents. Consents now point to client scopes, not to roles or protocol mappers. Because of this change, the previously confirmed persistent consents by users are not valid anymore and users need to confirm the consent page again after the migration.

Some configuration switches removed

The switch Scope Param Required was removed from Role Detail. The switches Consent Required and Consent Text were removed from the Protocol Mapper details. Those switches were replaced by the Client Scope feature.

4.2. Migrating to 3.4.2

4.2.1. Added session_state parameter to OpenID Connect Authentication Response

The OpenID Connect Session Management specification requires that the parameter session_state is present in the OpenID Connect Authentication Response.

In past releases, we did not have this parameter, but now Keycloak adds this parameter by default, as required by the specification.

However, some OpenID Connect / OAuth2 adapters, and especially older Keycloak adapters, may have issues with this new parameter.

For example, the parameter will be always present in the browser URL after successful authentication to the client application. In these cases, it may be useful to disable adding the session_state parameter to the authentication response. This can be done for the particular client in the Keycloak admin console, in client details in the section with OpenID Connect Compatibility Modes, described in Compatibility with older adapters. There is the Exclude Session State From Authentication Response switch, which can be turned on to prevent adding the session_state parameter to the Authentication Response.

The parameter session_state was added in 3.4.2, however the switch Exclude Session State From Authentication Response was added in 4.0.0.Beta1. If your Keycloak server is on 3.4.2 or 3.4.3 and you have issues with session_state parameter, you will need to upgrade the server to 4.0.0.Beta1 or newer.

4.3. 3.2.0への移行

4.3.1. 新しいパスワード・ハッシュ・アルゴリズム

2つの新しいパスワード・ハッシュ・アルゴリズム(pbkdf2-sha256とpbkdf2-sha512)を追加しました。新しいレルムでは、27500ハッシュ・イテレーションでpbkdf2-sha256ハッシュ・アルゴリズムを使用されます。pbkdf2-sha256はpbkdf2よりは多少速いため、そのイテレーションは20000から27500に増加されました。

既存のレルムは、パスワードポリシーにハッシュ・アルゴリズム(未指定)とイテレーション(20000)のデフォルト値が含まれている場合、アップグレードされます。ハッシュ・イテレーションを変更しており、セキュリティー上より安全なハッシュ・アルゴリズムを使用したい場合は、手動でpbkdf2-sha256に変更する必要があります。

4.3.2. IDトークンにはscope=openidが必要

OpenID Connectの仕様では、初回の認証要求において、 openid の値を持つパラメーターである scope を使用する必要があります。そのため、Keycloak 2.1.0では、KeycloakへのURIへリダイレクトする際に scope=openid を使用するように、アダプターを変更しました。また、サーバー部分も変更され、 scope=openid が実際に使用される場合にのみ、IDトークンがアプリケーションに送信されます。 scope=openid が使用されない場合は、IDトークンはスキップされ、アクセス・トークンとリフレッシュ・トークンだけがアプリケーションに送信されます。これにより、目的に応じて(たとえば、容量やパフォーマンスなどの目的で)、IDトークンの生成を省略することもできます。

ダイレクト・グラント(OAuth2リソース・オーナー・パスワード・クレデンシャル・グラント)とサービス・アカウント・ログイン(OAuth2クライアント・クレデンシャル・グラント)でも、IDトークンはデフォルトで使用されません。IDトークンを含めるには、敢えて scope=openid パラメーターを追加する必要があります。

4.3.3. 認証セッションとアクション・トークン

現在、Keycloakに対してマルチ・データセンターのサポートが実装されています。最初のステップとして、認証セッションとアクション・トークンを導入しました。認証セッションは、以前のバージョンで使用されていたクライアント・セッションを入れ替えたものになります。アクション・トークンは、現在、特殊なシナリオで使用されていますが、このシナリオにおいてはauthenticatorまたはrequiredActionProviderによってユーザーにEメールが送られ、ユーザーがEメールに記載されているリンクをクリックする必要があります。

これに関する具体的な変更は下記のとおりで、移行に影響を与えることになります。

これに関する1つ目の変更は、 standalone.xml または standalone-ha.xml 内の新しいInfinispanのキャッシュ authenticationSessionsactionTokens を導入したことです。移行CLIを使用している場合は、 standalone(-ha).xml ファイルは自動的に移行されるため、ほとんど気にする必要はありません。

2つ目の変更は、認証SPIのメソッドで複数の署名を変更したことです。この変更により、カスタム Authenticator または RequiredActionProvider を使用すると影響を受けることになります。クラス AuthenticationFlowContextRequiredActionContext によって、クライアント・セッションの代わりに認証セッションを取得することができます。

また、スティッキー・セッションの初回サポートも追加しました。パフォーマンスを上げたい場合は、ロードバランサーまたはプロキシー・サーバーを変更し、それを設定できます。ルートには新しい AUTH_SESSION_ID Cookieに追加されます。詳しくは、クラスター構成についてのドキュメントを参照してください。

別の変更点として、 token.getClientSession() が削除されたことがあります。これは、たとえば、クライアントの初回アイデンティティー・ブローカー・リンキング機能を使用している場合などに、影響を受ける可能性があります。

ScriptBasedAuthenticator のバインディング名が、 clientSession から authenticationSession に変更されました。そのため、このオーセンティケーターを使用している場合、スクリプトを更新する必要があります。

最後に、新しいタイムアウトを管理コンソールに追加しました。この追加によって、たとえば、管理者およびユーザー自身によってトリガーされた電子メール・アクションに異なるタイムアウトを指定することができます。

4.4. 2.5.1への移行

4.4.1. 古いオフライン・トークンの移行

2.2.0以前から移行してオフライン・トークンを使用した場合、オフライン・トークンは トークンのヘッダーにKIDを含んでいません。2.3.0では、複数のレルム鍵を持つ機能に加えて、KIDをトークン・ヘッダーに追加しました。そのため、KeycloakはトークンのKIDに基づく正しい鍵を見つけることができます。

KIDを含まないオフライン・トークンの場合、Keycloak 2.5.1はトークンの検証に適した鍵を見つけるため、常にアクティブなレルム鍵を使用します。言い換えると、古いオフライン・トークンが移行されることになります。そのため、たとえば、ユーザーが1.9.8でオフライン・トークンを要求すると、1.9.8から2.5.1に移行されたとき、ユーザーは2.5.1であっても古いオフライン・トークンをリフレッシュできることになります。

しかし、これには制限があります。アクティブなレルム鍵をいったん変更すると、ユーザーは古いオフライン・トークンを更新することができなくなります。したがって、オフライン・トークンを使用している全ユーザーが自身のトークンを更新するまで、アクティブ・レルム鍵を変更すべきではありません。新しく更新されたトークンには、確実にヘッダーにKIDが付与されます。そのため、全ユーザーが自身の古いオフライン・トークンを更新した後は、アクティブなレルム鍵を自由に変更することができます。

4.5. 2.5.0への移行

4.5.1. Infinispanキャッシュへの変更

standalone.xml または standalone-ha.xml 設定ファイル内のInfinispanサブシステムで定義された realms キャッシュには、現在、デフォルトで10000レコードのエビクションが用意されています。 users キャッシュにも、同じようにデフォルト値が設定されています。

また、 authorization キャッシュにはデフォルトではエビクションは用意されていません。

4.6. 2.4.0への移行

4.6.1. Server SPIをServer SPIとSever SPI Privateへ分割

keycloak-server-spiモジュールは、keycloak-server-spiとkeycloak-server-spi-privateに分割されています。今後のマイナーリリースにおいて、keycloak-server-spi内のAPIは変更しませんが、keycloak-server-spi-private内のAPIは変更する可能性が十分にあります。

4.6.2. SAMLアサーションのキーの暗号化アルゴリズム

現在、SAMLアサーション内のキーとドキュメントは、RSA-OAEP暗号化方式を使用して暗号化されています。暗号化されたアサーションを使用する場合、サービスプロバイダーがこの暗号化方式を理解していることを確認してください。稀なケースながら、SPがこの新しい方式を処理できない場合は、システム・プロパティー keycloak.saml.key_trans.rsa_v1.5true に設定して起動すると、KeycloakはレガシーなRSA-v1.5暗号化方式を使用することができます。

4.6.3. realmsとusersのInfinispanキャッシュは常にロ-カル

クラスター内でKeycloakを使用する場合でも、 standalone-ha.xml 内のインフィニスパン・サブシステム内で定義されたキャッシュ realmsusers は、現在常にローカル・キャッシュです。これらとは別に、クラスター・ノード間で無効化メッセージの送信し、クラスター全体に、 realmsusers キャッシュの前提となるレコードの内どれが無効となるのかを知らせるキャッシュ work というものがあります。

4.7. 2.3.0への移行

4.7.1. ページネーションされたエンドポイントのデフォルト最大値

現在、ページネーションをサポートするすべてのAdmin REST APIエンドポイントで、最大結果件数のデフォルトは100に設定されています。100を超えるエントリーを返す場合は、敢えて ?max=<RESULTS> を使用して、それを指定する必要があります。

4.7.2. realm-public-key アダプター・プロパティーは推奨されません

2.3.0リリースには、公開鍵ローテーションへのサポートを追加しました。管理者がKeycloak管理コンソールでレルム鍵のローテーションを行うと、クライアント・アダプターはそれを認識し、自動的に新しい公開鍵をKeycloakからダウンロードすることができます。ただし、ハードコーディングされた公開鍵を持つアダプターに realm-public-key オプションが指定されていない場合にのみ、この新しい鍵の自動ダウンロードは実行されます。このため、アダプター設定では realm-public-key オプションの使用は推奨されません。

このオプションは引き続きサポートはされていますが、アダプター設定でハードコーディングされた公開鍵を使用し、Keycloakから公開鍵をダウンロードしない場合にのみ便利です。この方法を使用する理論上の理由としては、アダプターとKeycloakの間に信頼できないネットワークがある場合に中間者攻撃を避けることができるという理由になりますが、実際はその場合、HTTPSを使用する方がはるかに良いです。HTTPSを使用すれば、アダプターとKeycloakの間のすべてのリクエストはセキュリティー上安全です。

4.7.3. Infinispanキャッシュ keys の追加

このリリースでは、 standalone.xml または standalone-ha.xml 設定ファイルで定義されたInfinispanサブシステムに、新しいキャッシュ keys を追加しました。これには、エビクションと期限があります。このキャッシュは、サーバーによって信頼されるエンティティーの外部公開鍵をキャッシュするために内部的に使用されます(署名されたJWTでの認証を使用するアイデンティティー・プロバイダーまたはクライアント)。

4.8. 2.2.0への移行

4.8.1. databaseSchema プロパティーの廃止

現在、JPAとMongoの両方の databaseSchema プロパティーは廃止され、 initializeEmptymigrationStrategy によって置き換えられています。 initializeEmptytrue または false に設定することができ、空のデータベースを初期化すべきかどうかを制御します。 migrationStrategyupdatevalidate および manual に設定することができます。 manual はリレーショナル・データベースでのみサポートされており、SQLファイルを作成してデータベース・スキーマに必要な変更を加えます。Oracle Databaseの場合は、作成されたSQLファイルには、OracleのSQLクライアントが理解できる SET DEFINE OFF コマンドが含まれています。他のクライアントがこのスクリプトを使用する場合は、変数の展開を無効にするためのツールの同等のコマンドで行を置換するか、そのような機能が適用されない場合は完全に削除してください。

4.8.2. クライアントの有効なリダイレクトURIの変更

以下のシナリオは、影響を受けることになります。

  • クエリー・コンポーネントを持つ有効なリダイレクトURIがクライアント(サンプルとしては http://localhost/auth?foo=bar )で保存された場合、認証要求の redirect_uri はこのURI(または、このクライアントで登録された他のURI)と完全に一致する必要があります。

  • クエリー・コンポーネントを持たない有効なリダイレクトURIがクライアントに保存された場合も、 redirect_uri はこのURIと完全に一致する必要があります。

  • 登録済みの有効なリダイレクトURIのワイルドカードは、クエリー・コンポーネントを持っていない場合、もはやサポートされません。そのため、 redirect_uri はこの登録済みのURIとも同様に一致する必要があります。

  • 登録済みの有効なリダイレクトURI( http://localhost/auth#fragment など)内のフラグメントはもはや許可されません。

4.8.3. アイデンティティー・プロバイダーからデフォルトで削除された認証

アイデンティティー・プロバイダーには、デフォルトの認証プロバイダーとして設定されるオプションはもはやありません。その代わり、認証に移動して Browser フローを選択し、 Identity Provider Redirector を設定します。デフォルトのアイデンティティー・プロバイダーを設定するオプションがあります。

4.9. 2.0.0への移行

4.9.1. 1.0.0.Finalからのアップグレードはもはやサポートされません

1.0.0.Finalからのアップグレードはもうサポートされません。2.0.0へアップグレードするには、その前に1.9.8.Finalへアップグレードしてください。

4.10. 1.9.5への移行

4.10.1. デフォルトのパスワード・ハッシュ間隔は20Kに増加

新しいレルムのためにデフォルトでパスワードをハッシングする間隔は、(以前の1から) 20Kに増加されました。この変更により、ユーザー認証時のパフォーマンスが影響を受けることになります。たとえば、以前のデフォルト(1)ではパスワードをハッシングするのに1ミリ秒もかかりませんでしたが、新しいデフォルト(20K)では50から100ミリ秒かかります。

4.11. 1.9.3への移行

4.11.1. ユーザー追加スクリプトの名前の変更

Keycloakの管理者ユーザーを追加するスクリプトの名前を、 add-user-keycloak へ変更しました。

4.12. 1.9.2への移行

4.12.1. アダプターオプションauth-server-url-for-backend-requestsを削除

オプションauth-server-url-for-backend-requestsは削除しました。このオプションが使用されると、いくつかのシナリオに問題が生じたためです。具体的には、2つの異なるコンテキスト(内部および外部)からKeycloakサーバーへのアクセスが可能だったのですが、このことがトークンを検証する際などに問題を起こしていました。

それでも、このオプションが提供する(アプリケーションがバックチャネル・リクエストをロードバランサーを通じて送るのではなく、ローカルのKeycloakサーバーに直接送るという)ネットワークの最適化を使用したい場合は、ホスト設定(DNS)レベルで処理する必要があります。

4.13. 1.9.0への移行

4.13.1. テーマとプロバイダーのディレクトリーを移動

テーマとプロバイダーのディレクトリーを standalone/configuration/themesstandalone/configuration/providers から themesproviders へそれぞれ移動させました。カスタマイズしたテーマとプロバイダーを追加している場合は、それらを新しい場所に移動させる必要があります。また、このことによって変更されたとおりに、 keycloak-server.json を更新する必要もあります。

4.13.2. アダプター・サブシステムはKeycloakが有効な場合にのみ依存関係となる

Previously, if you had installed our SAML or OIDC Keycloak subsystem adapters into WildFly or JBoss EAP, we would automatically include Keycloak client jars into EVERY application irregardless if you were using Keycloak or not. These libraries are now only added to your deployment if you have Keycloak authentication turned on for that adapter (via the subsystem, or auth-method in web.xml)

4.13.3. クライアント登録サービスのエンドポイントを移動

クライアント登録サービスのエンドポイントは、 {realm-name}/clients から {realm-name}/clients-registrations へ移動しました。

4.13.4. 認証レスポンスのセッション・ステートのパラメーター名を変更

OpenID Connectの認証レスポンスにおけるセッション状態を session-state というキー名にしていましたが、これは仕様上間違っていたため、 session_state に変更しました。

4.13.5. いくつかのOpenID Connectエンドポイントを廃止

1.2では、OpenID Connectの仕様と合わないエンドポイントを大量に廃止し、現在は削除されています。これは、1.8で新しいイントロスペクト・エンドポイントに置き換えられた、トークン検証エンドポイントにも適用されます。

4.13.6. テーマのテンプレートを更新

template.ftlのフィードバックを移動し、フォーマットをわずかに変更しました。

4.13.7. モジュールとソースコードを再編

モジュールとソースコードのほとんどは、keycloak-server-spiおよびkeycloak-servicesという、2つのmavenモジュールに統合されました。 SPIのインターフェイスはserver-spiに、実装はkeycloak-servicesに統合されています。すべてのJPA依存のモジュールはkeycloak-model-jpaに統合されました。mongoとInfinispanも同様で、keycloak-model-mongoとkeycloak-model-infinispanのモジュールに統合されています。

4.13.8. アダプターによりログイン後のセッションIDを変更

To plug a security attack vector, for platforms that support it (Tomcat 8, Undertow/WildFly, Jetty 9), the Keycloak OIDC and SAML adapters will change the session id after login. You can turn off this behavior check adapter config switches.

4.13.9. SAML SPクライアント・アダプターの変更

現在、KeycloakのSAML SPクライアント・アダプターは、IDPで登録されるために、特定のエンドポイント /saml を要求します。

4.14. 1.8.0への移行

4.14.1. 管理者アカウント

以前のリリースでは、デフォルトのパスワードでデフォルトの管理者ユーザーを設定していましたが、現在はこれを削除しています。1.8の新規のインストールでは、最初の手順として管理者ユーザーを作成する必要があります。

4.14.2. OAuth2トークン・イントロスペクション

OAuth2の仕様により合わせるために、トークン・イントロスペクション用の新しいエンドポイントを追加しました。新しいエンドポイントは /realms/{realm-name}/protocols/openid-connect/token/introspect で取得することができ、 RFC-7662 にのみ基づいています。

/realms/{realm-name}/protocols/openid-connect/validate エンドポイントは現在廃止されています。新しいイントロスペクション・エンドポイントにできるだけ早く移動することを強くお勧めします。この変更の理由は、RFC-7662が、より標準的でセキュリティー上安全なイントロスペクション・エンドポイントが提供していることです。

新しいトークン・イントロスペクションURLは、現在 /realms/{realm-name}/.well-known/openid-configuration 上のOpenID Connectプロバイダーの設定から取得することができます。このレスポンス内に、 token_introspection_endpoint という名前のクレームがあります。 confidential clients だけがこの新しいエンドポイントを呼び出すことが許可されており、そこでは、これらのクライアントは通常、リソースサーバーとして機能し、ローカルの認可チェックを実施するために、トークンのメタデータを検索します。

4.15. 1.7.0.CR1への移行

4.15.1. クライアントのダイレクト・アクセス・グラントをデフォルトで無効化

OpenID Connectの仕様により合わせるために、管理コンソールのClient Settingsのページにフラグを追加しました。そのページでは、さまざまな種類のOpenID ConnectまたはOAuth2のフロー(Standard flow、Implicit flow、Direct Access Grants、Service Accounts)を有効または無効にすることができます。この一環として、新規クライアント用にはデフォルトで無効となっている Direct Access Grants (OAuth2 Resource Owner Password Credentials Grant に対応)があります。

以前のバージョンから移行されたクライアントは、 Direct Grants Only フラグがオンである場合のみ、 Direct Access Grants が有効になります。ダイレクト・アクセス・グラントを有効にし、スタンダード + インプリシットの両方のフローを無効にした場合と同等の、`Direct Grants Only`フラグは削除されました(同じ効果となるため)。

また、組み込みのクライアント admin-cli を各レルムに追加しました。このクライアントは Direct Access Grants が有効になっています。そのため、Admin REST APIまたはKeycloak admin-clientを使用している場合は、 security-admin-console の代わりに admin-cli を使用するように設定を更新する必要があります。現在、後者はデフォルトでダイレクト・アクセス・グラントが有効になっていないためです。

4.15.2. オプション’Update Profile On First Login’をアイデンティティー・プロバイダーからレビュー・プロファイル・オーセンティケーターへ移動

このバージョンで、 First Broker Login を追加しました。この追加により、新規ユーザーがアイデンティティー・プロバイダー(またはソーシャル・プロバイダー)を介してログインした際に、厳密に何を実行する必要があるのかを指定できるようになりました。この一環として、 First Login Flow オプションをアイデンティティー・プロバイダーに追加しました。これにより、フローを特定し、管理コンソール内の Authentication タブでこのフローを設定することができるようになりました。

また、 Update Profile On First Login オプションをアイデンティティー・プロバイダー設定から削除し、 Review Profile オーセンティケーターの設定に移動させました。そのため、アイデンティティー・プロバイダー用にはどのフローを使う必要があるのかを指定すれば(デフォルトでは First Broker Login フローとなっていますが)、 Authentication タブに移動してフローを選択し、 Review Profile オーセンティケーターの下にあるオプションで設定することができます。

4.15.3. web.xml内の 'form-error-page' 要素のサポートを終了

web.xml内のform-error-pageはもはやクライアント・アダプター認証エラーにより動作しません。さまざまなHTTPエラーコード用にerror-pageを定義する必要があります。アダプターのエラー条件を確認および処理したい場合、詳細はドキュメントを参照してください。

4.15.4. IdentityProviderMapperの変更

インターフェイス自体またはメソッドのシグネチャーに、変更はありません。しかし、動作には変更がいくつかあります。このリリースでは First Broker Login フローを追加し、 メソッド IdentityProviderMapper.importNewUserFirst Broker Login フローが完了した後に呼び出されるようになりました。そのため、Review Profile ページ任意の属性を利用できるようにするには、 importNewUser の代わりに preprocessFederatedIdentity メソッドを使用する必要があります。 BrokeredIdentityContext.setUserAttribute を呼び出して属性を設定することができ、それを Review profile ページで利用できます。

4.16. 1.6.0.Finalへの移行

4.16.1. リフレッシュ・トークンを再利用しないオプション

Keycloakの古いバージョンでは、リフレッシュ・トークンを何回でも再利用することができました。Keycloakではこの再利用はいまだに許可されていますが、 Revoke refresh token オプションでこれを許可しないこともできます。このオプションは管理コンソールのトークン設定配下にあります。新しいアクセス・トークンが取得するためにリフレッシュ・トークンが使用された場合、新しいリフレッシュ・トークンもそこに含まれることになります。オプションが有効である場合は、次にアクセス・トークンがリフレッシュされた際に、この新しいリフレッシュ・トークンを使用する必要があります。古いリフレッシュ・トークンを何回も再利用することはできません。

4.16.2. パッケージの名前がいくつか変更されました

いくつかのパッケージの構成と名前を少し変更しました。主にutilクラスの内部パッケージ名の変更です。アプリケーション(たとえば、AccessTokenまたはKeycloakSecurityContext)で使用される最も重要なクラスとSPIは変更されていません。ただし、影響を受けたりクラスのインポートを更新する必要がでてきたりする可能性がわずかながらあります。たとえば、multitenancyとKeycloakConfigResolverを使用している場合は、HttpFacadeクラスが別のパッケージ(これは現時点では org.keycloak.adapters.spi.HttpFacade です。)に移動されたのと同じように、影響を受けます。

4.16.3. ユーザー・セッションの永続化

このリリースにはオフライン・トークンのサポートを追加しました。つまり、 "offline" ユーザー・セッションは現在データベース内で永続化されているということです。オフライン・トークンを使用していない場合は、何も永続化されていませんので、 DBに追加で書き込むとパフォーマンスが低下するのではないかと心配する必要はありません。しかし、いかなる場合でも、 standalone/configuration/keycloak-server.json を更新し、以下のように userSessionPersister を追加する必要があります。

"userSessionPersister": {
 "provider": "jpa"
},

昔のRDBMSの代わりに、Mongo内でセッションを永続化させたい場合は、 mongo プロバイダーを代用してください。

4.17. 1.5.0.Finalへの移行

4.17.1. レルムとユーザーのキャッシュ・プロバイダー

Infinispanは現在デフォルトでレルムとユーザーのキャッシュ・プロバイダーのみとなっています。非クラスターモードでは、ローカルのInfinispanキャッシュが使用されます。 また、カスタムのin-memoryキャッシュと非キャッシュ・プロバイダーは削除しました。realmCacheまたはuserCacheがkeycloak-server.jsonでmemまたはnoneに設定されている場合は、それらを削除してください。Infinispanは、realmCacheとuserCacheのオブジェクトをもはや必要としない唯一のプロバイダーなので、それらを削除することができます。

4.17.2. ユーザー・セッション・プロバイダー

Infinispanは現在デフォルトで唯一のユーザー・セッション・プロバイダーです。非クラスター・モードでは、ローカルのInfinispanキャッシュが使用されます。また、JPAとMongoユーザー・セッション・プロバイダーを削除しました。ユーザー・セッションをkeycloak-server.jsonでmem、jpaまたはmongoに設定している場合、それを削除してください。Infinispanは、ユーザー・セッションのオブジェクトをもはや必要としない唯一のプロバイダーなので、それを削除することができます。

ユーザー・セッションの耐久性を上げたい場合、ユーザー・セッション・キャッシュを一人以上の所有者で設定するか、または複製したキャッシュを使用します。また、Infinispanを設定してキャッシュを保持させる方法でも可能です。ただし、パフォーマンスに影響を与える可能性があります。

4.17.3. コンタクト詳細を登録とアカウント管理から削除

デフォルトのテーマでは、登録ページとアカウント管理からコンタクト詳細を現在削除してあります。管理コンソールには、特定のコンタクト属性だけでなく、現在すべてのユーザー属性がリスト表示されます。また、管理コンソールには、ユーザーに属性を追加したり削除したりする機能があります。コンタクト詳細を追加する場合は、サンプルに含まれているアドレス・テーマを参照してください。

4.18. 1.3.0.Finalへの移行

4.18.1. ダイレクト・グラントAPIは常に有効

以前は、ダイレクト・グラントAPI(またはリソース・オーナー・パスワード・クレデンシャル)はデフォルトで無効となっており、レルムのオプションによってそれを有効にすることができました。現在は、ダイレクト・グラントAPIは常に有効で、レルムで有効または無効にできるオプションは削除されています。

4.18.2. データベースの変更

データベースの変更はほとんどありません。アップグレードする前にデータベースを忘れずバックアップしてください。

4.18.3. UserFederationProviderの変更

UserFederationProviderインターフェイスの変更はわずかなマイナーチェンジのみです。新しいバージョンにアップグレードする際に実装を同期させ、シグネチャーを変更したいくつかのメソッドをアップグレードする必要があるかもしれません。変更は本当にわずかですが、フェデレーションのパフォーマンスを上げるために必要でした。

4.18.4. WildFly 9.0.0.Final

最新リリースで実行された配布物の変更に伴って、現在Keycloakのスタンドアローン・ダウンロードはWildFly 9.0.0.Finalに基づいています。また、これはオーバーレイにも影響を及ぼし、WildFly 9.0.0.FinalまたはJBoss EAP6.4.0.GAにのみこのオーバーレイをデプロイすることができるようになりました。WildFly 8.2.0.Finalはサーバー用にサポートされなくなりました。

4.18.5. WildFly、JBoss EAPおよびJBoss AS7アダプター

下記のとおり、WildFly、JBoss EAPおよびJBoss AS7用の3つの別のアダプター・ダウンロードがあります。

  • eap6

  • wf9

  • wf8

  • as7

適切なものを選ぶよう注意してください。

また、拡張モジュールとサブシステム定義が変更されたので、standalone.xmlを更新する必要があります。詳しくは、{adapterguide_nameを参照してください。

4.19. 1.2.0.Beta1から1.2.0.RC1への移行

4.19.1. 配布物の変更

現在、Keycloakは3つのダウンロードで使用することができます。スタンドアローン、オーバーレイおよびデモ・バンドルの3つになります。スタンドアローンはプロダクションと非JEE開発者用に作られたものです。オーバーレイは既存のWildFly 8.2またはEAP 6.4環境へのKeycloakの追加を目的としており、主に開発用に作られたものです。最後にデモ(または開発)バンドルについてですが、これは開発者がKeycloakをはじめられるように作られたものです。このバンドルには、Keycloakサーバーとアダプターだけでなく、WildFlyサーバーも含まれます。また、すべてのドキュメントとサンプルも含まれています。

4.19.2. データベースの変更

このリリースには、データベース上の変更点がいくつかあります。最も大きな変更は、アプリケーションとOAuthのクライアントのマージです。アップグレードする前に、データベースを忘れずにバックアップしてください。

4.19.3. アプリケーションとOAuthクライアントのマージ

現在、アプリケーションとOAuthクライアントは Clients にマージされています。管理コンソールのUIは更新されており、データベースも同様です。データベースのデータは自動的に更新されます。以前に設定されたアプリケーションは Consent required スイッチがオフのクライアントに変換され、OAuthクライアントはこのスイッチがオンのクライアントに変換されます。

4.20. 1.1.0.Finalから1.2.0.Beta1への移行

4.20.1. データベースの変更

このリリースには、データベース上の変更点がいくつかあります。アップグレードする前に、データベースを忘れずにバックアップしてください。

4.20.2. アクセス・トークンとIDトークン内の iss

アクセス・トークンとIDトークン内の iss クレームの値は、 realm name から realm url へ変更されました。これはOpenID Connectの仕様の要求によるものです。アダプターを使用している場合は変更の必要はありませんが、 auth-server-url を指定せずにbearer-onlyだけを使用していた場合は変更する必要があります。別のライブラリ(またはRSATokenVerifier)を使用している場合は、 iss の検証時に対応できるよう変更を加える必要があります。

4.20.3. OpenID Connectエンドポイント

OpenID Connect仕様に合わせるために、認証とトークンのエンドポイントは、単一の認証エンドポイントと単一のトークン・エンドポイントを持つように変更されました。仕様どおりに response_typegrant_type パラメーターが使用され、必要なフローを選択できるようになります。古いエンドポイント( /realms/{realm-name}/protocols/openid-connect/login , /realms/{realm-name}/protocols/openid-connect/grants/access , /realms/{realm-name}/protocols/openid-connect/refresh , /realms/{realm-name}/protocols/openid-connect/access/codes )は現在廃止されており、今後の新しいバージョンでは削除されます。

4.20.4. テーマの変更

テーマのレイアウトを変更しました。以前はディレクトリーの階層は type/name でしたが、現在は name/type に変更されています。たとえば、 sunrise という名前のログイン・テーマは、以前は standalone/configuration/themes/login/sunrise にデプロイされていましたが、現在は standalone/configuration/themes/sunrise/login に移されています。この変更は、同じテーマの異なるタイプのグループを1つのフォルダに保存するのを簡単にするために実施しました。

以前は、テーマをJARとしてデプロイした場合、Javaコードが必要なカスタム・テーマ・ローダーを作成する必要がありました。現在は、これが簡略化され、簡単なテキストファイル( META-INF/keycloak-themes.json )だけで、JARに含まれるテーマを記述できるようになりました。

4.20.5. クレームの変更

以前は、アプリケーションとOAuthクライアント用に、管理コンソール内に Claims タブがありました。これは、特定のアプリケーションまたはクライアント用に、どの属性をアクセス・トークンに入れるのかを設定するために使用していました。このタブは削除し、より柔軟性が高いプロトコル・マッパーに置き換えました。

以前のバージョンからのデータベースの移動については気にする必要はありません。RDBMSとMongoの両方用の移行スクリプトの実行により、特定のアプリケーションまたはクライアント用に設定されたクレームは、対応するプロトコル・マッパーに変更されるようになりました(そうは言っても、新しいバージョンに移行する前にDBをバックアップしておいた方が安全です)。以前のバージョンからエクスポートされたJSONの記述についても、同様になります。

4.20.6. ソーシャルをアイデンティティー・ブローカリングへ移行

ソーシャル・プロバイダーSPIを、リファクタリングしてアイデンティティー・ブローカリングSPIに置き換えました。この方が柔軟性が高いです。管理コンソール内の Social タブは Identity Provider タブに名前が変更されました。

また、クレーム/プロトコル・マッパーと同様に、以前のバージョンからのデータベース移行について気にする必要はありません。ソーシャル・プロバイダーの設定とユーザーへの "social links" の両方は、対応するアイデンティティー・プロバイダーに変換されます。

実施すべきことは、特定のサード・パーティーのソーシャル・プロバイダーの管理コンソール内にある許可済みの Redirect URI に変更することのみです。まず、Keycloak管理コンソールに移動し、アイデンティティー・プロバイダーを設定したページからRedirect URIをコピーします。次に、サード・パーティーのプロバイダーの管理コンソール(たとえばFacebookの管理コンソール)に、許可されたRedirect URIとしてこれをペーストするだけです。

4.21. 1.1.0.Beta1から1.1.0.Beta2への移行

  • 現在、アダプターは別途ダウンロードすることになっています。これはアプライアンスやwar配布物には含まれていません。現在配布物にはあまりに多くのものが含まれていて、肥大化している状態です。

  • org.keycloak.adapters.tomcat7.KeycloakAuthenticatorValve + org.keycloak.adapters.tomcat.KeycloakAuthenticatorValve`

  • 現在、JavaScriptアダプターには、idTokenとidTokenParsedプロパティーがあります。idTokenを使用してファーストネームやEメールなどを取得する場合、これをidTokenParsedに変更する必要があります。

  • as7-eap-subsystemとkeycloak-wildfly-subsystemは、1つのkeycloak-subsystemに統合されました。既存のstandalone.xmlまたはdomain.xmlを持っている場合は、ファイルの先頭あたりを編集し、拡張モジュール名をorg.keycloak.keycloak-subsystemに変更する必要があります。AS7だけは、拡張モジュール名がorg.keycloak.keycloak-as7-subsystemになります。

  • サーバーのインストールはAS7ではサポートされなくなりました。それでも、AS7はアプリケーション・クライアントとして使用することができます。

4.22. 1.0.x.Finalから1.1.0.Beta1への移行

  • RealmModel JPAとMongoストレージ・スキーマが変更されました

  • UserSessionModel JPAとMongoストレージ・スキーマは、これらのインターフェイスがリファクタリングされたので、変更されました

  • アダプターをアップグレードしてください。古いアダプターはKeycloak 1.1と互換性がありません。JSON Web TokenとOIDC ID Tokenの仕様は間違って解釈されていました。 'aud' クレームはクライアントIDでなければなりませんが、そこにレルム名が格納されて検証されていました。

4.23. 1.0 RC-1からRC-2への移行

  • 情報レベルのロギングの多くがデバッグレベルに変更されました。また、デフォルトではレルムにjboss-logging監査リスナーが無くなりました。ユーザーがログイン、ログアウト、パスワードの変更などをする際にログの出力が必要な場合は、管理コンソールでjboss-logging監査リスナーを有効にしてください。

4.24. 1.0 Beta 4からRC-1への移行

  • ログアウトREST APIはリファクタリングされました。ログアウトURIのGETリクエストはsession_stateパラメーターを取得しなくなりました。セッションをログアウトするには、ログインする必要があります。また、ログアウトREST URIにPOSTすることもできます。このアクションでは、ログアウトするために有効なリフレッシュ・トークンが必要です。シグネチャーは、パラメーターからグラント・タイプを差し引いたリフレッシュ・トークンと同じものです。詳しくは、ドキュメントを参照してください。

4.25. 1.0 Beta 1からBeta 4への移行

  • LDAP/AD設定は変更されました。これは "Settings" ページには存在しなくなりました。現在はUsers→Federationにあります。プロバイダーの追加には、 "ldap" オプションが表示されます。

  • 認証SPIは削除されて書き換えられました。新しいSPIはUserFederationProviderで、より柔軟性が高くなっています。

  • ssl-not-required +ssl-required +all +external +none

  • DBスキーマは再度変更されました。

  • 新規作成されたアプリケーションは、デフォルトでフルスコープを持つようになりました。つまり、必要ない場合は、アプリケーションのスコープを設定する必要はありません。

  • レルムデータをインポートするためのJSONファイルのフォーマットが変更されました。現在は特定のユーザーのJSONレコードでロール・マッピングを使用することができます。

4.26. 1.0 Alpha 4からBeta 1への移行

  • DBスキーマが変更されました。Beta 1へデータベースのエクスポートを追加しましたが、古いバージョンからデータベースをインポートすることはできませんでした。これについては、今後のリリースでサポートされることになります。

  • ベアラー専用のアプリケーションを除いてクライアントはすべて、少なくとも1つのリダイレクトURIを指定する必要があります。そのアプリケーション用の有効なリダイレクトURIを指定しないと、Keycloakへのログインは許可されません。

  • Direct Grant API +ON

  • standalone/configuration/keycloak-server.json

  • JavaScriptアダプター

  • セッション・タイムアウト

4.27. 1.0 Alpha 2からAlpha 3への移行

  • SkeletonKeyToken、SkeletonKeyScope、SkeletonKeyPrincipal、およびSkeletonKeySessionは、それぞれAccessToken、AccessScope、KeycloakPrincipal、およびKeycloakAuthenticatedSessionに名前が変更されました。

  • ServletOAuthClient.getBearerToken()メソッドのシグネチャーが変更されました。現在は、AccessTokenResponseが返されて、リフレッシュ・トークンも取得できるようになりました。

  • 現在、アダプターはリクエストの度にアクセス・トークンの期限を確認します。トークンが期限切れになっていると、アダプターは保存されたリフレッシュ・トークンを使用して、認証サーバー上でリフレッシュを実行しようとします。

  • AccessTokenの件名がUser IDに変更されました。

4.28. 1.0 Alpha 1からAlpha 2への移行

  • DBスキーマが変更されました。Alpha 2の時点では、データ移行ユーティリティーはまだありません。

  • JBoss and WildFly adapters are now installed via a WildFly subsystem. Please review the adapter installation documentation. Edits to standalone.xml are now required.

  • 新しいクレデンシャル・タイプの "secret" 画追加されました。他のクレデンシャル・タイプと異なり、データベース内のプレーンテキストに保存されていて、管理コンソールで確認することができます。

  • アプリケーションまたはOAuthクライアントのクレデンシャルは必要なくなりました。現在、これらのクライアント・タイプは "secret" クレデンシャル・タイプを使用するようにハードコードされています。

  • アプリケーションとOAuthクライアントに対する "secret" クレデンシャルの変更により、管理コンソールのアプリケーションまたはOAuthクライアント・クレデンシャルのタブで、keycloak.json設定ファイルを更新してシークレットを再生成する必要があります。