Keycloak 4.5.0.Final

Signature SPI

The Signature SPI makes it possible to plug-in additional signature algorithms. This enables additional signatures and also enables changing how signatures are generated. For example, using this allows using an HSM device to sign tokens.

Thanks to tnorimat for contributing a signficant part of this work.

New Signature Algorithms

Alongside the Signature SPI there is now also support for additional signature algorithms.

Keycloak now has support for RS256, RS384, RS512, ES256, ES384, ES512, HS256, HS384 and HS512.

Elliptic Curve Digital Signature Algorithm (ES256/384/512) are very interesting as they provide similar security properties as RSA signatures, but use significantly less CPU.

HMAC (HS256/384/512) are also very useful when you do not want your application to verify the signature itself. Since these are symmetric signatures only Keycloak is able to verify the signature, which requires the application to use the token introspection endpoint to verify tokens.

Thanks to tnorimat for contributing a signficant part of this work.

Better Audience Support for OpenID Connect clients

It is now possible to specify the audiences in the tokens issued for OpenID Connect clients. There is also support for verification of audience on the adapter side.

Minor improvements

  • Added LocaleSelector SPI, which allows to change the way how the locale will be resolved for a particular request. Thanks to knutz3n

  • Added an authenticator to automatically link Identity Provider identity to an existing account after first Idp authentication. Thanks to slominskir

Keycloak 4.4.0.Final

Upgrade to WildFly 13

The Keycloak server was upgraded to use WildFly 13 under the covers. This means update of the underlying dependencies and also some changes in the configuration. We now also support WildFly 13 adapter and we upgraded the underlying JDG/Infinispan server version for the Cross-DC setup. See Upgrading Guide for more details.

Authorization Services support in Node.js

Having authorization services support in Node.js makes it very easy to do fine-grained central authorization with the Node.js adapter.

Minor improvements

  • Update design for the welcome page

  • Allow passing current locale to OAuth2 IdPs. Thanks to knutz3n

  • Support Content-Security-Policy-Report-Only security header. Thanks to knutz3n

  • Script based ProtocolMapper for SAML. Thanks to AlistairDoswald

Keycloak 4.3.0.Final

Hostname SPI

The hostname SPI introduces a more flexible way to configure the hostname for Keycloak. There are two built-in providers. The first is request, which uses the request headers to determine the hostname. The second is fixed, which allows configuring a fixed hostname. The latter makes sure that only valid hostnames can be used and also allows internal applications to invoke Keycloak through an alternative URL.

For more details refer to the threat mitigation section in the Server Administration Guide.

X509 Client Authenticator

The newly added Client Authenticator uses X509 Client Certificates and Mutual TLS to secure a connection from the client. In addition to that the Keycloak Server validates Subject DN field of the client’s certificate.

Performance improvements to Authorization Services

For this release, we improved policy evaluation performance across the board, increasing reliability and throughput. The main changes we did were related with trying to optimize the policy evaluation path by avoiding unnecessary flows and collect decisions as soon as they happen. We also introduced a policy decision cache on a per request basis, avoiding redundant decisions from policies previously evaluated.

We are also working on other layers of cache which should give a much better experience. See KEYCLOAK-7952.

Choosing the response mode when obtaining permissions from the server

In previous versions, permissions were always returned from the server using standard OAuth2 response, containing the access and refresh tokens. In this release, clients can use a response_mode parameter to specify how the server should respond to an authorization request. This parameter accepts two values:

  • decision

    Indicating that responses should only contain a flag indicating whether or not permissions were granted by the server. Otherwise a 403 HTTP status code is returned.

  • permissions

    Indicating that a response should contain every single permission granted by the server using a JSON format.

NodeJS Policy Enforcer

The keycloak-nodejs-connect, an adapter for NodeJS, now supports constructs to protect resources based on decisions taken from the server. The new construct allows users to protect their resources using fine-grained permissions as follows:

app.get('/protected/resource', keycloak.enforcer('resource:view'), function (req, res) {
  res.json({message: 'access granted'});
});

Support hosted domain for Google logins

Login with Google now supports the hd parameter to restrict Google logins to a specific hosted domain at Google. When this is specified in the identity provider any login from a different domain is rejected.

Thanks to brushmate for the contribution.

Escape unsafe tags in HTML output

Most HTML output is already escaped for HTML tags, but there are some places where HTML tags are permitted. These are only where admin access is needed to update the value. Even though it would require admin access to update such fields we have added an extra layer of defence and are now escaping unsafe elements like <script>.

Keycloak 4.2.0.Final

Browser tab support for Cordova

We now have support for using browser tab and universal links in the JavaScript adapter for Cordova. This enables SSO between multiple applications as well as increases security.

Thanks to gtudan for the contribution.

SAML adapter multitenancy support

The SAML adapter can support multi-tenancy now just like the built in adapter for OpenID Connect.

An option to create claims with dots (.) in them

In previous versions, it was not possible to create claims in the token using a claim name containing a dot (.) character. Now it is possible to escape the dot character in the configuration, so a claim name with the dot character can be used.

Keycloak 4.1.0.Final

Making Spring Boot 2 the default starter

Starting with release 4.1, the Spring Boot starter will be based on the Spring Boot 2 adapter. If you are using an older Spring Boot version, the keycloak-legacy-spring-boot-starter is available.

Keycloak 4.0.0.Final

クライアント・スコープとOAuth 2スコープ・パラメーターのサポート

クライアント・テンプレートに代わるクライアント・スコープのサポートが追加されました。クライアント・スコープは、より柔軟なアプローチであり、OAuthの scope パラメーターに対してより良いサポートを提供します。

同意画面には、クライアント・スコープに関する変更があります。同意画面のリストは、プロトコル・マッパーとロールの代わりにクライアント・スコープにリンクされるようになりました。

詳細については、マニュアルおよび移行ガイドを参照してください。

OAuth 2 Certificate Bound Access Tokens

OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokensの仕様の部分実装が行われました。より正確には、Certificate Bound Access Tokenをサポートしました。コンフィデンシャル・クライアントが双方向SSLを使用できる場合、Keycloakはクライアント用に発行されたトークンにクライアント証明書のハッシュを追加できます。現在のところ、Keycloak自体だけで、トークンハッシュを検証します(例えば、 refresh token リクエストの間)。アダプターにもサポートを追加する予定です。Mutual TLSクライアント認証のサポートも追加する予定です。

tnorimatのコントリビューションに感謝します。

認可サービス

UMA 2.0 Support

UMA 2.0 is now supported for Authorization Services. Check the documentation for more details if you are coming from previous versions of Keycloak.

User-Managed Access through the Keycloak Account Service

Now end-users are able to manage their resources and the permissions associated with them through the Keycloak Account Service. From there, resource owners can now check their resources, share resources with another users as well approve requests from other users.

Asynchronous Authorization Flow

When using UMA, client applications can now choose whether or not an authorization request should start an authorization flow to ask for the resource owner approval. This functionality allows applications to ask for resource owner approval when trying to access one of his resources on behalf of another user.

User-Managed Permission API

Resource servers are now capable of associating additional policies to resources owned by a particular user. The new API provides operations to manage these permissions using different policy types such as role, group, user, client or a condition using JavaScript.

クレームのプッシュ

Clients applications are now able to send arbitrary claims to Keycloak along with an authorization request in order to evaluate permissions based on these claims. This is a very handy addition when access should be granted (or denied) in the scope of a specific transaction or based on information about the runtime.

リソース属性

It is now possible to associated attributes with resources protected by Keycloak and use these same attributes to evaluate permissions from your policies.

Policy enforcer now accepts regular access tokens

In some situations, you may want to just send regular access tokens to a resource server but still be able to enforce policies on these resources.

One of the main changes introduced by this release is that you are no longer required to exchange access tokens with RPTs in order to access resources protected by a resource server (when not using UMA). Depending on how the policy enforcer is configured on the resource server side, you can just send regular access tokens as a bearer token and permissions will still be enforced.

Policy enforcer can now load resources from the server on-demand

Until now, when deploying an application configured with a policy-enforcer, the policy enforcer would either load all protected paths from the server or just map these paths from the adapter configuration. Users can now decide to load paths on-demand from the server and avoid map these resources in the adapter configuration. Depending on how many protected resources you have this functionality can also improve the time to deploy an application.

Policy enforcer now supports configuring the resource cache

In order to avoid unnecessary hits to the server, the policy enforcer caches the mapping between protected resources and their corresponding paths in your application. Users can now configure the behaviour of the cache or even completely disable it.

Claim Information Points

The policy-enforcer definition on the adapters (keycloak.json) was also updated to support the concept of pushed claims. There you have the concept of a claim-information-point which can be set to push claims from different sources such as the HTTP request or even from an external HTTP service.

Improvements to the Evaluation API

The Evaluation API used to implement policies in Keycloak, especially JavaScript and Drools policies, provides now methods to:

  • Access information from the current realm such as check for user roles, groups and attributes

  • Push back arbitrary claims to the resource server in order to provide additional information on how a specific permissions should be enforced

認可サービス

UMA 2.0

ユーザーがアカウント管理コンソールを介してユーザーアクセスを管理できるようにするなど、UMA 2.0が認可サービスでサポートされるようになりました。認可サービスには、他にも追加や改良があります。

クレームのプッシュ

パーミッションを評価するときに、クライアントが追加のクレームをプッシュし、ポリシーで使用されるようにすることが可能になりました。

リソース属性

パーミッションを評価するときに、リソースの属性を定義して、ポリシーで使用されるようにすることが可能になりました。

テーマとテーマのリソース

通常のプロバイダー配備で、テーマをKeycloakにホットデプロイできるようになりました。テーマリソースのサポートも追加しました。テーマを作成せずにテンプレートとリソースを追加することができます。これは、認証フローに追加されるページを必要とするカスタム・オーセンティケーターにとって便利です。

特定のクライアントのテーマを無効にするサポートも追加しました。それがニーズに合っていない場合は、カスタムロジックを実装してテーマを選択できる新しいテーマセレクターSPIもあります。

Instagramアイデンティティー・プロバイダー

Instagramでログインするためのサポートが追加されました。 hguerrero からのコントリビュートに感謝します。

管理コンソールでのユーザーIDによる検索

管理コンソールでIDを使用してユーザーを検索するには、以前はURLを編集する必要がありましたが、ユーザー検索フィールドで直接検索することが可能になりました。

アダプター

Spring Boot 2

Spring Boot 2をサポートしました。

Fuse 7

Fuse 7をサポートしました。

JavaScript - ネイティブPromiseのサポート

JavaScriptアダプターは、ネイティブのPromiseをサポートするようになりました。古いスタイルのPromiseも、今までどおりサポートしています。どちらも区別せずに使用できます。

JavaScript - Cordovaオプション

JavaScriptアダプターのログインやその他のメソッドにCordova固有のオプションを渡すことができるようになりました。 loorent からのコントリビュートに感謝します。