curated list may need further edits
This commit is contained in:
parent
9e927159ed
commit
588978d2cf
1 changed files with 162 additions and 0 deletions
162
release_notes/topics/7_3_final.adoc
Normal file
162
release_notes/topics/7_3_final.adoc
Normal file
|
@ -0,0 +1,162 @@
|
|||
= Overview
|
||||
|
||||
The Red Hat Single Sign-On (RH-SSO) Server, based on the Keycloak project, enables you to secure your web applications by providing Web SSO capabilities based on popular standards such as SAML 2.0, OpenID Connect, and OAuth 2.0. The Server can act as a SAML or OpenID Connect–based identity provider (IdP), mediating with your enterprise user directory or third-party identity provider for identity information and your applications using standards-based tokens.
|
||||
|
||||
The following notes apply to the RH-SSO 7.3 release.
|
||||
|
||||
= Fixed Issues
|
||||
More than 1,200 issues were resolved in this release.
|
||||
|
||||
* link:https://issues.jboss.org/issues/?filter=12337585[https://issues.jboss.org/issues/?filter=12337585]
|
||||
|
||||
= New or Improved Feature Overview
|
||||
|
||||
Some of the new features in this release are technology preview features, which means they are available, but not fully supported. You may use these for testing, but features marked for technology preview will not be supported if used in production. These are marked as technology preview in this list and in our documentation. Because they are not fully supported for production use, technology preview features are disabled by default, but the features can be enabled if you want to try them out. We are seeking feedback on the technology preview features, so please log a support ticket if you have comments on a technology preview feature.
|
||||
|
||||
== Authorization Services
|
||||
|
||||
Authorization Services was introduced as a technology preview feature back in the RH-SSO 7.1 release. In 7.3 it is now fully supported, except for a small subcomponent related to custom rules implemented using Drools, which remains Tech Preview.
|
||||
|
||||
Authorization Services has been upgraded to be based on the new User Managed Access 2.0 (UMA 2.0) specification. Previous releases relied on the UMA 1.0 version. Upgrading introduced the ability for users to manage their resources, associated permissions, approve requests to access and share them with other users through the account management console.
|
||||
|
||||
Many smaller improvements and additions have also been made:
|
||||
|
||||
* Resource attributes - It is now possible to define attributes on resources in order to have them used by policies when evaluating permissions.
|
||||
|
||||
* Adapter improvement - NodeJS adapter support for authorization services has been added.
|
||||
|
||||
* Improvements to the Evaluation API - Access information from the current realm such as checking 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.
|
||||
|
||||
* Asynchronous authorization flow - 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.
|
||||
|
||||
* Pushed claims - Client 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.
|
||||
|
||||
* Policy enforcer - The policy enforcer now accepts regular access tokens, longer requiring 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, regular access tokens as a bearer token can be leveraged.
|
||||
|
||||
* Additional changes - Performance improvements and optimizations with additional configuration options for further performance profiling depending on particular application needs.
|
||||
|
||||
The subcomponent related to custom rules implemented using Drools functionality is in technology preview and should not be used in production environments.
|
||||
|
||||
== New Capabilities in Client Adapters
|
||||
|
||||
* Fuse 7 - Fuse adapter aligned with latest Fuse 7 release
|
||||
|
||||
* Sprint Boot 2 support
|
||||
|
||||
* JavaScript -
|
||||
|
||||
** Native Promise Support - The JavaScript adapter now supports native promises. It retains support for the old style promises as well. Both can be used interchangeably.
|
||||
|
||||
** JavaScript - Cordova mode now allows passing Cordova-specific options to login and other methods in the JavaScript adapter.
|
||||
|
||||
* SAML adapter multitenancy support - allowing integrating with multiple Keycloak realms like already possible in OpenID Connect adapter.
|
||||
|
||||
== New Signature Algorithms
|
||||
|
||||
RH-SSO server now has support for RS256, RS384, RS512, ES256, ES384, ES512, HS256, HS384 and HS512.
|
||||
|
||||
Elliptic Curve Digital Signature Algorithm (ES256/384/512) is now supported and provides similar security properties as RSA signatures, but use significantly less CPU.
|
||||
|
||||
HMAC (HS256/384/512) is now supported and allows preventing an application from attempting 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.
|
||||
|
||||
RH-SSO adapters do not yet have support for the additional signature algorithms and currently only support RS256.
|
||||
|
||||
== Improved 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.
|
||||
|
||||
== Hostname Handling
|
||||
|
||||
We introduced a more flexible way to configure the hostname for RH-SSO which gives greater flexibility when deployed in Cloud-related environments. It can be determined based on request headers or configured as a fixed hostname. The latter makes sure that only valid hostnames can be used and also allows internal applications to invoke RH-SSO through an alternative URL.
|
||||
|
||||
== X509 Client Authenticator
|
||||
|
||||
The newly added Client Authenticator uses X509 Client Certificates and Mutual TLS to secure a connection from the client. In addition, the RH-SSO Server validates the Subject DN field of the client’s certificate.
|
||||
|
||||
== Client Scopes and support for OAuth 2 scope parameter
|
||||
|
||||
We added support for Client Scopes, which replace Client Templates. Client Scopes are a more flexible approach and also provide better support for the OAuth scope parameter.
|
||||
|
||||
There are changes related to Client Scopes to the consent screen. The list on the consent screen is now linked to client scopes instead of protocol mappers and roles.
|
||||
|
||||
See the documentation and the migration guide for more details.
|
||||
|
||||
== OAuth 2 Certificate Bound Access Tokens
|
||||
|
||||
We now have a partial implementation of the specification OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens. Specifically, we now have support for the Certificate Bound Access Tokens. If your confidential client is able to use 2-way SSL, RH-SSO will be able to add the hash of the client certificate into the tokens issued for the client. At this moment, it is just RH-SSO itself which verifies the token hashes (for example during refresh token requests). We plan to add support to adapters as well. We also plan to add support for Mutual TLS Client Authentication.
|
||||
Themes and Theme Resources
|
||||
|
||||
It is now possible to hot-deploy themes to RH-SSO through a regular provider deployment. We have also added support for theme resources, which allows adding additional templates and resources without creating a theme. This is useful for custom authenticators that require additional pages to be added to the authentication flow.
|
||||
|
||||
We have also added support to override the theme for specific clients. If that is not adequate for your needs, then there is also a new Theme Selector SPI that allows you to implement custom logic to select the theme.
|
||||
|
||||
== Instagram Identity Provider
|
||||
|
||||
We have added support to login with Instagram.
|
||||
|
||||
== Search by User ID in Admin Console
|
||||
|
||||
To search for a user by id in the admin console you previously had to edit the URL. It is now possible to search directly in the user search field.
|
||||
|
||||
== 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.
|
||||
|
||||
== 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 only exist where admin access is needed to update the value. Even though it would require admin access to update these, fields we have added an extra layer of defense and are now escaping unsafe elements like <script>.
|
||||
|
||||
== 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.
|
||||
|
||||
== 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.
|
||||
|
||||
== Minor improvements
|
||||
|
||||
* Authenticator to automatically link Identity Provider identity to an existing account after first Idp authentication.
|
||||
|
||||
* Update design for the welcome page
|
||||
|
||||
* Allow passing current locale to OAuth2 IdPs.
|
||||
|
||||
* Support Content-Security-Policy-Report-Only security header.
|
||||
|
||||
* Script based ProtocolMapper for SAML.
|
||||
|
||||
== OpenShift integration is in tech preview
|
||||
|
||||
RH-SSO now has the ability to replace the internal OpenShift IdP. This provides a better and tighter integration when securing OpenShift with RH-SSO. More details and documentation to follow. For now demo setup is available at https://github.com/keycloak/openshift-integration.
|
||||
|
||||
This functionality is in technology preview and should not be used in production environments.
|
||||
|
||||
== Rule-based policies in Authorization services is in tech preview
|
||||
|
||||
There remains a subcomponent of Authorization Services related to custom rules implemented using Drools functionality that is in technology preview and should not be used in production environments.
|
||||
|
||||
== Unsupported enhancements and SPIs that are in tech Preview
|
||||
|
||||
These are present, but should not be considered finalized or stable as they may change between release versions.
|
||||
|
||||
* Hostname SPI - This SPI makes it possible to implement custom handling of hostname evaluation.
|
||||
|
||||
* Signature SPI - This 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.
|
||||
|
||||
This functionality is in technology preview and should not be used in production environments.
|
||||
|
||||
= Supported Configurations
|
||||
|
||||
The set of supported features and configurations for RH-SSO Server 7.3 is available on the link:https://access.redhat.com/articles/2342861[Customer Portal].
|
||||
|
||||
= Component Versions
|
||||
|
||||
The list of supported component versions for RH-SSO 7.3 is available on the link:https://access.redhat.com/articles/2342881[Customer Portal].
|
||||
|
||||
= Known Issues
|
||||
The following are known issues for this release.
|
||||
|
||||
|
Loading…
Reference in a new issue