24 lines
3.8 KiB
Text
24 lines
3.8 KiB
Text
== About Changes from RH-SSO 7.0 to RH-SSO 7.1
|
|
|
|
The following changes have occurred from RH-SSO 7.0 to RH-SSO 7.1. Review these changes carefully before upgrading.
|
|
|
|
=== Realm Keys
|
|
For RH-SSO 7.0 only one set of keys could be associated with a realm. This meant that when changing the keys all current cookies and tokens would be invalidated and all users would have to re-authenticate. For RH-SSO 7.1 support for multiple keys for one realm has been added. At any given time one set of keys is the active keys used for signatures, but there can be multiple keys used to verify signatures. This means that old cookies and tokens can be verified, then refreshed with the new signatures, allowing users to remain authenticated when keys are changed. There are also some changes to how keys are managed through the Admin Console and Admin REST API; for more details see link:{adminguide_link}#realm_keys[Realm Keys] in the _{adminguide_name}_.
|
|
|
|
To allow seamless key rotation you must remove hard-coded keys from client adapters. The client adapters will automatically retrieve keys from the server as long as the realm key is not specified. Client adapters will also retrieve new keys automatically when keys are rotated.
|
|
|
|
=== Client Redirect URI Matching
|
|
For RH-SSO 7.0 query parameters are ignored when matching valid redirect URIs for a client. For RH-SSO 7.1 query parameters are no longer ignored. If you need to include query parameters in the redirect URI you must specify the query parameters in the valid redirect URI for the client (for example, \https://hostname/app/login?foo=bar) or use a wildcard (for example, \https://hostname/app/login/*). Fragments are also no longer permitted in Valid Redirect URIs (that is, \https://hostname/app#fragment).
|
|
|
|
=== Automatically Redirect to Identity Provider
|
|
For RH-SSO 7.1, identity providers cannot be set as the default authentication provider. To automatically redirect to an identity provider for RH-SSO 7.1 you must now configure the identity provider redirector. For more information see link:{adminguide_link}#default_identity_provider[Default Identity Provider] in the _{adminguide_name}_. If you previously had an identity provider with the default authentication provider option set, this value is automatically used as the value for the identity provider redirector when the server is upgraded to RH-SSO 7.1.
|
|
|
|
=== Admin REST API
|
|
For RH-SSO 7.0 paginated endpoints in the Admin REST API return all results if the maxResults query parameter was not specified. This could cause issues with a temporary high load and requests timing out when a large number of results were returned (for example, users). For RH-SSO 7.1 a maximum of 100 results are returned if a value for maxResults is not specified. You can return all results by specifying maxResults as -1.
|
|
|
|
=== Server Configuration
|
|
For RH-SSO 7.0 server configuration is split between the keycloak-server.json file and the standalone/domain.xml or domain.xml file. For RH-SSO 7.1 the keycloak-server.json file has been removed and all server configuration is done through the standalone.xml or domain.xml file. The upgrading procedure for RH-SSO 7.1 automatically migrates the server configuration from the keycloak-server.json file to the standalone.xml or domain.xml file.
|
|
|
|
=== Key Encryption Algorithm in SAML Assertions
|
|
For RH-SSO 7.1, keys in SAML assertions and documents are now encrypted using the RSA-OAEP encryption scheme. To use encrypted assertions, ensure your service providers support this encryption scheme. In the event that you have service providers that do not support RSA-OAEP, RH-SSO can be configured to use the legacy RSA-v1.5 encryption scheme by starting the server with the system property “keycloak.saml.key_trans.rsa_v1.5” set to true. If you do this you should upgrade your service providers as soon as possible to be able to revert to the more secure RSA-OAEP encryption scheme.
|
|
|