Cleaning old product documentation from the upstream documentation
Closes #27324 Signed-off-by: Alexander Schwartz <aschwart@redhat.com>
This commit is contained in:
Alexander Schwartz
Alexander Schwartz
parent
a3f91ef95b
commit
3950b4ed46
22 changed files with 1 additions and 1185 deletions
Binary file not shown.
|
Before Width: | Height: | Size: 28 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 131 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 47 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 112 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 41 KiB |
|
|
@ -1,11 +1,3 @@
|
|||
ifeval::[{project_product}==true]
|
||||
include::topics/rhsso/intro.adoc[leveloffset=0]
|
||||
include::topics/rhsso/changes.adoc[leveloffset=0]
|
||||
include::topics/rhsso/upgrading.adoc[leveloffset=0]
|
||||
endif::[]
|
||||
|
||||
ifeval::[{project_community}==true]
|
||||
include::topics/keycloak/intro.adoc[leveloffset=0]
|
||||
include::topics/keycloak/upgrading.adoc[leveloffset=0]
|
||||
include::topics/keycloak/changes.adoc[leveloffset=0]
|
||||
endif::[]
|
||||
include::topics/keycloak/changes.adoc[leveloffset=0]
|
||||
|
|
@ -1,24 +0,0 @@
|
|||
== RH-SSO 7.1
|
||||
|
||||
The following changes have occurred from RH-SSO 7.0 to RH-SSO 7.1.
|
||||
|
||||
=== 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 set used for creating 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.
|
||||
|
||||
|
|
@ -1,91 +0,0 @@
|
|||
== RH-SSO 7.2
|
||||
|
||||
The following changes have occurred from RH-SSO 7.1 to RH-SSO 7.2.
|
||||
|
||||
=== New password hashing algorithms
|
||||
|
||||
We have added two new password hashing algorithms (pbkdf2-sha256 and pbkdf2-sha512). New realms will use the pbkdf2-sha256
|
||||
hashing algorithm with 27500 hashing iterations. Since pbkdf2-sha256 is slightly faster than pbkdf2 the iterations was
|
||||
increased to 27500 from 20000.
|
||||
|
||||
Existing realms are upgraded if the password policy contains the default value for the hashing algorithm (not specified) and
|
||||
iteration (20000). If you have changed the hashing iterations, you need to manually change to pbkdf2-sha256 if you'd like
|
||||
to use the more secure hashing algorithm.
|
||||
|
||||
=== ID Token requires scope=openid
|
||||
|
||||
In RH-SSO 7.0, the ID Token was returned regardless if `scope=openid` query parameter was present or not in authorization
|
||||
request. This is incorrect according to the OpenID Connect specification.
|
||||
|
||||
In RH-SSO 7.1, we added this query parameter to adapters, but left the old behavior to accommodate migration.
|
||||
|
||||
In RH-SSO 7.2, this behavior has changed and the `scope=openid` query parameter is now required to mark the request as an
|
||||
OpenID Connect request. If this query parameter is omitted the ID Token will not be generated.
|
||||
|
||||
=== Microsoft SQL Server requires extra dependency
|
||||
|
||||
Microsoft JDBC Driver 6.0 requires additional dependency added to the JDBC driver module. If you observe an
|
||||
`NoClassDefFoundError` error when using Microsoft SQL Server please add the following dependency to your JDBC driver
|
||||
`module.xml` file:
|
||||
|
||||
[source,xml]
|
||||
----
|
||||
<module name="javax.xml.bind.api"/>
|
||||
----
|
||||
|
||||
=== 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 RH-SSO 7.1, we did not have this parameter, but now {project_name} adds this parameter by default, as required by the specification.
|
||||
|
||||
However, some OpenID Connect / OAuth2 adapters, and especially older {project_name} adapters (such as RH-SSO 7.1 and older), 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.
|
||||
If you use RH-SSO 7.1 or a legacy OAuth2 / OpenID Connect adapter, 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 {project_name} 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.
|
||||
|
||||
=== Microsoft Identity Provider updated to use the Microsoft Graph API
|
||||
|
||||
The Microsoft Identity Provider implementation in {project_name} up to version 7.2.4 relies on the Live SDK
|
||||
endpoints for authorization and obtaining the user profile. From November 2018 onwards, Microsoft is removing support
|
||||
for the Live SDK API in favor of the new Microsoft Graph API. The {project_name} identity provider has been updated
|
||||
to use the new endpoints so if this integration is in use make sure you upgrade to {project_name} version 7.2.5 or later.
|
||||
|
||||
Legacy client applications registered under "Live SDK applications" won't work with the Microsoft Graph endpoints
|
||||
due to changes in the id format of the applications. If you run into an error saying that the application identifier
|
||||
was not found in the directory, you will have to register the client application again in the
|
||||
https://account.live.com/developers/applications/create[Microsoft Application Registration] portal to obtain a new application id.
|
||||
|
||||
=== Google Identity Provider updated to use Google Sign-in authentication system
|
||||
|
||||
The Google Identity Provider implementation in {project_name} up to version 7.2.5 relies on the Google+ API endpoints
|
||||
for authorization and obtaining the user profile. From March 2019 onwards, Google is removing support
|
||||
for the Google+ API in favor of the new Google Sign-in authentication system. The {project_name} identity provider has been updated
|
||||
to use the new endpoints so if this integration is in use make sure you upgrade to {project_name} version 7.2.6 or later.
|
||||
|
||||
If you run into an error saying that the application identifier was not found in the directory, you will have to register the client application again in the
|
||||
https://console.cloud.google.com/apis/credentials[Google API Console] portal to obtain a new application id and secret.
|
||||
|
||||
It is possible that you will need to adjust custom mappers for non-standard claims that were provided by Google+ user
|
||||
information endpoint and are provided under different name by Google Sign-in API. Please consult Google documentation
|
||||
for the most up-to-date information on available claims.
|
||||
|
||||
=== LinkedIn Social Broker updated to Version 2 of LinkedIn APIs
|
||||
|
||||
Accordingly with LinkedIn, all developers need to migrate to version 2.0 of their APIs and OAuth 2.0. As such, we have updated
|
||||
our LinkedIn Social Broker so if this integration is in use make sure you upgrade to {project_name} version 7.2.6 or later.
|
||||
|
||||
Existing deployments using this broker may start experiencing errors when fetching user's profile using version 2 of
|
||||
LinkedIn APIs. This error may be related with the lack of permissions granted to the client application used to configure the broker
|
||||
which may not be authorized to access the Profile API or request specific OAuth2 scopes during the authentication process.
|
||||
|
||||
Even for newly created LinkedIn client applications, you need to make sure that the client is able to request the `r_liteprofile` and
|
||||
`r_emailaddress` OAuth2 scopes, at least, as well that the client application can fetch current member's profile from the `https://api.linkedin.com/v2/me` endpoint.
|
||||
|
||||
Due to these privacy restrictions imposed by LinkedIn in regards to access to member's information and the limited set of claims returned by the
|
||||
current member's Profile API, the LinkedIn Social Broker
|
||||
is now using the member's email address as the default username. That means that the `r_emailaddress` is always set when
|
||||
sending authorization requests during the authentication.
|
||||
|
|
@ -1,169 +0,0 @@
|
|||
== RH-SSO 7.3
|
||||
|
||||
The following changes have occurred from RH-SSO 7.2 to RH-SSO 7.3.
|
||||
|
||||
=== Changes to authorization services
|
||||
|
||||
We added support for UMA 2.0. This version of the UMA specification introduced some important changes on how permissions are obtained from the server.
|
||||
|
||||
Here are the main changes introduced by UMA 2.0 support. See link:{authorizationguide_link}[{authorizationguide_name}] for details.
|
||||
|
||||
Authorization API was removed::
|
||||
Prior to UMA 2.0 (UMA 1.0), client applications were using the Authorization API to obtain permissions from the server in the format of an RPT. The new version
|
||||
of UMA specification has removed the Authorization API which was also removed from {project_name}. In UMA 2.0, RPTs can now be obtained from the token endpoint by using a specific grant type.
|
||||
See link:{authorizationguide_link}#_service_obtaining_permissions[{authorizationguide_name}] for details.
|
||||
|
||||
Entitlement API was removed::
|
||||
With the introduction of UMA 2.0, we decided to leverage the token endpoint and UMA grant type to allow obtaining RPTs from {project_name} and
|
||||
avoid having different APIs. The functionality provided by the Entitlement API was kept the same and is still possible to obtain permissions for a set
|
||||
of one or more resources and scopes or all permissions from the server in case no resource or scope is provided.
|
||||
See link:{authorizationguide_link}#_service_obtaining_permissions[{authorizationguide_name}] for details.
|
||||
|
||||
Changes to UMA Discovery Endpoint::
|
||||
UMA Discovery document changed, see link:{authorizationguide_link}#_service_authorization_api[{authorizationguide_name}] for details.
|
||||
|
||||
Changes to {project_name} Authorization JavaScript adapter::
|
||||
The {project_name} Authorization JavaScript adapter (keycloak-authz.js) changed in order to comply with the changes introduced by UMA 2.0 while keeping
|
||||
the same behavior as before. The main change is on how you invoke both `authorization` and `entitlement` methods which now
|
||||
expect a specific object type representing an authorization request. This new object type provides more flexibility on how
|
||||
permissions can be obtained from the server by supporting the different parameters supported by the UMA grant type.
|
||||
See link:{authorizationguide_link}#_enforcer_js_adapter[{authorizationguide_name}] for details.
|
||||
|
||||
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.
|
||||
|
||||
Changes to {project_name} Authorization Client Java API::
|
||||
When upgrading to the new version of {project_name} Authorization Client Java API, you'll notice that some representation classes
|
||||
were moved to a different package in `org.keycloak:keycloak-core`.
|
||||
|
||||
=== 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.
|
||||
|
||||
=== New default client scopes
|
||||
We have added new realm default client scopes `roles` and `web-origins`. These client scopes contain protocol
|
||||
mappers to add the roles of the user and allowed web origins to the token. During migration, these client scopes should be
|
||||
automatically added to all the OpenID Connect clients as default client scopes. Hence no setup should be required after database
|
||||
migration is finished.
|
||||
|
||||
==== Protocol mapper SPI addition
|
||||
Related to this, there is a small addition in the (unsupported) Protocol Mappers SPI. You can be affected only if you
|
||||
implemented a custom ProtocolMapper. There is a new `getPriority()` method on the ProtocolMapper interface. The method has the
|
||||
default implementation set to return 0. If your protocol mapper implementation relies on the roles in the access token `realmAccess`
|
||||
or `resourceAccess` properties, you may need to increase the priority of your mapper.
|
||||
|
||||
==== Audience resolving
|
||||
|
||||
Audiences of all the clients, for which authenticated user has at least one client role in the token, are automatically added
|
||||
to the `aud` claim in the access token now. On the other hand, an access token may not automatically contain the audience of the
|
||||
frontend client, for which it was issued. See the link:{adminguide_link}#_audience_resolve[{adminguide_name}] for more details.
|
||||
|
||||
=== Upgrade to EAP 7.2
|
||||
|
||||
The {project_name} server was upgraded to use EAP 7.2 as the underlying container. This does not directly involve any
|
||||
specific {project_name} server functionality, but there are few changes related to the migration, which worth mentioning.
|
||||
|
||||
Dependency updates::
|
||||
The dependencies were updated to the versions used by EAP 7.2 server. For example, Infinispan is now 9.3.1.Final.
|
||||
|
||||
Configuration changes::
|
||||
There are few configuration changes in the `standalone(-ha).xml` and `domain.xml` files. You should follow the <<_install_new_version>>
|
||||
section to handle the migration of configuration files automatically.
|
||||
|
||||
Cross-Datacenter Replication changes::
|
||||
* You will need to upgrade {jdgserver_name} server to version {jdgserver_version}. The older version may still work, but it is
|
||||
not guaranteed as we don't test it anymore.
|
||||
ifeval::[{project_product}==true]
|
||||
* There is a need to add `protocolVersion` property with the value `2.6` to the configuration of the `remote-store` element in the
|
||||
{project_name} configuration. This is required as there is a need to downgrade the version of HotRod protocol to be compatible
|
||||
with the version used by {jdgserver_name} {jdgserver_version}.
|
||||
endif::[]
|
||||
|
||||
=== Hostname configuration
|
||||
|
||||
In previous versions it was recommended to use a filter to specify permitted hostnames. It is now possible to
|
||||
set a fixed hostname which makes it easier to make sure the valid hostname is used and also allows internal
|
||||
applications to invoke {project_name} through an alternative URL, for example an internal IP address. It is
|
||||
recommended that you switch to this approach in production.
|
||||
|
||||
=== JavaScript adapter promise
|
||||
|
||||
To use native JavaScript promise with the JavaScript adapter it is now required to set `promiseType` to `native` in the
|
||||
init options.
|
||||
|
||||
In the past if native promise was available a wrapper was returned that provided both the legacy Keycloak promise and
|
||||
the native promise. This was causing issues as the error handler was not always set prior to the native error event, which
|
||||
resulted in `Uncaught (in promise)` error.
|
||||
|
||||
=== Microsoft Identity Provider updated to use the Microsoft Graph API
|
||||
|
||||
The Microsoft Identity Provider implementation in {project_name} used to rely on the Live SDK
|
||||
endpoints for authorization and obtaining the user profile. From November 2018 onwards, Microsoft is removing support
|
||||
for the Live SDK API in favor of the new Microsoft Graph API. The {project_name} identity provider has been updated
|
||||
to use the new endpoints so if this integration is in use make sure you upgrade to the latest {project_name} version.
|
||||
|
||||
Legacy client applications registered under "Live SDK applications" won't work with the Microsoft Graph endpoints
|
||||
due to changes in the id format of the applications. If you run into an error saying that the application identifier
|
||||
was not found in the directory, you will have to register the client application again in the
|
||||
https://account.live.com/developers/applications/create[Microsoft Application Registration] portal to obtain a new application id.
|
||||
|
||||
=== Google Identity Provider updated to use Google Sign-in authentication system
|
||||
|
||||
The Google Identity Provider implementation in {project_name} used to rely on the Google+ API endpoints
|
||||
for authorization and obtaining the user profile. From March 2019 onwards, Google is removing support
|
||||
for the Google+ API in favor of the new Google Sign-in authentication system. The {project_name} identity provider has been updated
|
||||
to use the new endpoints so if this integration is in use make sure you upgrade to the latest {project_name} version.
|
||||
|
||||
If you run into an error saying that the application identifier was not found in the directory, you will have to register the client application again in the
|
||||
https://console.cloud.google.com/apis/credentials[Google API Console] portal to obtain a new application id and secret.
|
||||
|
||||
It is possible that you will need to adjust custom mappers for non-standard claims that were provided by Google+ user
|
||||
information endpoint and are provided under different name by Google Sign-in API. Please consult Google documentation
|
||||
for the most up-to-date information on available claims.
|
||||
|
||||
=== LinkedIn Social Broker Updated to Version 2 of LinkedIn APIs
|
||||
|
||||
Accordingly with LinkedIn, all developers need to migrate to version 2.0 of their APIs and OAuth 2.0. As such, we have updated
|
||||
our LinkedIn Social Broker.
|
||||
|
||||
Existing deployments using this broker may start experiencing errors when fetching user's profile using version 2 of
|
||||
LinkedIn APIs. This error may be related with the lack of permissions granted to the client application used to configure the broker
|
||||
which may not be authorized to access the Profile API or request specific OAuth2 scopes during the authentication process.
|
||||
|
||||
Even for newly created LinkedIn client applications, you need to make sure that the client is able to request the `r_liteprofile` and
|
||||
`r_emailaddress` OAuth2 scopes, at least, as well that the client application can fetch current member's profile from the `https://api.linkedin.com/v2/me` endpoint.
|
||||
|
||||
Due to these privacy restrictions imposed by LinkedIn in regards to access to member's information and the limited set of claims returned by the
|
||||
current member's Profile API, the LinkedIn Social Broker
|
||||
is now using the member's email address as the default username. That means that the `r_emailaddress` is always set when
|
||||
sending authorization requests during the authentication.
|
||||
|
|
@ -1,119 +0,0 @@
|
|||
== RH SSO 7.4
|
||||
|
||||
The following changes have occurred from {project_name} 7.3 to {project_name} 7.4.
|
||||
|
||||
=== Upgrade to EAP 7.3
|
||||
|
||||
The {project_name} server was upgraded to use EAP 7.3 as the underlying container. This change does not directly involve any specific {project_name} server functionality, but a few changes relate to the migration.
|
||||
|
||||
==== Dependency updates
|
||||
|
||||
The dependencies were updated to the versions used by EAP 7.3 server. For example, the Infinispan component version is now 9.3.1.Final.
|
||||
|
||||
==== Configuration changes
|
||||
|
||||
There are a few configuration changes in the standalone(-ha).xml and domain.xml files. Follow the Upgrading the {project_name} server section to handle the migration of configuration files automatically.
|
||||
|
||||
==== Cross-Datacenter replication changes
|
||||
|
||||
You will need to upgrade {jdgserver_name} to version {jdgserver_version}. The older version may still work, but it is not tested so it is not guaranteed to work.
|
||||
|
||||
=== Authentication flows changes
|
||||
|
||||
We did some refactoring and improvements related to the authentication flows, which requires attention during migration.
|
||||
|
||||
==== REQUIRED and ALTERNATIVE executions not supported at same authentication flow
|
||||
|
||||
Previously, it was possible to have REQUIRED and ALTERNATIVE executions in the same authentication flow at the same level. There were some issues with this approach and we did the refactoring in the Authentication SPI, which means that this is no longer valid. If ALTERNATIVE and REQUIRED executions are configured at the same level, the ALTERNATIVE executions are considered disabled.
|
||||
|
||||
So when migrating to this version, your existing authentication flows will be migrated but retain the behavior of the previous version. If an authentication flow contains ALTERNATIVE executions at the same level as REQUIRED executions, the ALTERNATIVE executions are added to the separate REQUIRED subflow.
|
||||
|
||||
This strategy should ensure the same or similar behavior of each authentication flow as in the previous version. However, you may review the configuration of your authentication flow and double check that it works as expected. This recommendation applies in particular for customized authentication flows with custom authenticator implementations.
|
||||
|
||||
==== OPTIONAL execution requirement removed
|
||||
|
||||
Regarding migration, the most important change is removing support for the OPTIONAL requirement from authentication executions and replacing it with the CONDITIONAL requirement, which allows more flexibility.
|
||||
|
||||
OPTIONAL authenticators configured in the previous version are replaced with the CONDITIONAL subflows. These subflows have the Condition - User Configured condition configured as first execution, and the previously OPTIONAL authenticator (for example OTP Form) as second execution. For the user, the behavior during authentication matches the behavior of the previous version.
|
||||
|
||||
==== SPI Changes
|
||||
|
||||
Some changes exist in the Java Authentication SPI and Credential Provider SPI.
|
||||
|
||||
The interface Authenticator is not changed, but you may be affected if you develop advanced authenticators that introduce some new credential types (subclasses of CredentialModel). Changes exist on the CredentialProvider interface and introduction of some new interfaces such as CredentialValidator.
|
||||
|
||||
Also, you may be affected if your authenticator supported the OPTIONAL execution requirement. It is recommended that you double-check the latest authentication examples in the server development guide for more details.
|
||||
|
||||
==== Freemarker template changes
|
||||
|
||||
Changes exist in the freemarker templates. You may be affected if you have your own theme with custom freemarker templates for login forms or some account forms, especially for the forms related to OTP. We recommend that you review the changes in the Freemarker templates in this version and align your templates according to it.
|
||||
|
||||
=== Duplicated top level groups
|
||||
|
||||
This release fixes a problem which could create duplicated top level groups in the realm. Nevertheless the existence
|
||||
of previous duplicated groups makes the upgrade process fail. The {project_name} server can be affected by this issue
|
||||
if it is using an H2, MariaDB, MySQL or PostgreSQL database. Before launching the upgrade, check if the server contains
|
||||
duplicated top level groups. For example, the following SQL query can be executed at database level to list them:
|
||||
|
||||
----
|
||||
SELECT REALM_ID, NAME, COUNT(*) FROM KEYCLOAK_GROUP WHERE PARENT_GROUP is NULL GROUP BY REALM_ID, NAME HAVING COUNT(*) > 1;
|
||||
----
|
||||
|
||||
Only one top level group can exist in each realm with the same name. Duplicates should be reviewed and deleted before the
|
||||
upgrade. The error in the upgrade contains the message `Change Set META-INF/jpa-changelog-9.0.1.xml::9.0.1-
|
||||
KEYCLOAK-12579-add-not-null-constraint::keycloak failed.`
|
||||
|
||||
=== User credentials changes
|
||||
|
||||
We added more flexibility around storing user credentials. Among other things, every user can have multiple credentials of the same type, such as multiple OTP credentials. Some changes exist in the database schema in relation to that, however the credentials from the previous version are updated to the new format. Users can still log in with the passwords or OTP credentials defined in the previous version.
|
||||
|
||||
=== New optional client scope
|
||||
|
||||
We have added a microprofile-jwt optional client scope to handle the claims defined in the MicroProfile/JWT Auth Specification. This new client scope defines protocol mappers to set the username of the authenticated user to the upn claim and to set the realm roles to the groups claim.
|
||||
|
||||
=== Improved handling of user locale
|
||||
|
||||
A number of improvements have been made to how the locale for the login page is selected, as well as when the locale is updated for a user. See the link:{adminguide_link}[{adminguide_name}] for more details.
|
||||
|
||||
=== Legacy promise in JavaScript adapter
|
||||
|
||||
You no longer need to set promiseType in the JavaScript adapter, and both are available at the same time. It is recommended to update applications to use native promise API (then and catch) as soon as possible, as the legacy API (success and error) will be removed at some point.
|
||||
|
||||
=== Deploying Scripts to the Server
|
||||
|
||||
Until now, administrators were allowed to upload scripts to the server through the {project_name} Admin Console and the RESTful Admin API. This capability is now disabled. Users should deploy scripts directly to the server. For more details, review the link:{developerguide_jsproviders_link}[{developerguide_jsproviders_name}].
|
||||
|
||||
|
||||
=== Client Credentials in the JavaScript adapter
|
||||
|
||||
In the previous releases, developers were allowed to provide client credentials to the JavaScript adapter. For now on, this capability was removed, because client-side apps are not safe to keep secrets.
|
||||
Ability to propagate prompt=none to default IDP
|
||||
|
||||
We have added a switch in the OIDC identity provider configuration named Accepts prompt=none forward from client to identify IDPs that are able to handle forwarded requests that include the prompt=none query parameter.
|
||||
|
||||
Until now, when receiving an auth request with prompt=none, a realm would return a login_required error if the user is not authenticated in the realm without checking if the user has been authenticated by an IDP. From now on, if a default IDP can be determined for the auth request (either by the use of the kc_idp_hint query param or by setting up a default IDP for the realm) and if the Accepts prompt=none forward from client switch has been enabled for the IDP, the auth request is forwarded to the IDP to check if the user has been authenticated there.
|
||||
|
||||
It is important to note that this switch is only taken into account if a default IDP is specified, in which case we know where to forward the auth request without having to prompt the user to select an IDP. If a default IDP cannot be determined, we cannot assume which one will be used to fulfill the auth request so the request forwarding is not performed.
|
||||
|
||||
=== New Default Hostname provider
|
||||
|
||||
The request and fixed hostname providers have been replaced with a new default hostname provider. The request and fixed hostname providers are now deprecated and we recommend that you switch to the default hostname provider as soon as possible.
|
||||
|
||||
=== Deprecated or removed features
|
||||
|
||||
Certain features have a change in status.
|
||||
|
||||
==== Deprecated methods in token representation Java classes
|
||||
|
||||
In the year 2038, an int is no longer able to hold the value of seconds since 1970, as such we are working on updating these to long values. In token representation there is a further issue. An int will by default result in 0 in the JSON representation, while it should not be included.
|
||||
|
||||
See the link:{apidocs_javadocs_link}[{apidocs_javadocs_name}] for further details on exact methods that have been deprecated and replacement methods.
|
||||
|
||||
==== Uploading scripts
|
||||
|
||||
Upload of scripts through admin rest endpoints/console is deprecated. It will be removed at a future release.
|
||||
|
||||
=== Authorization Services Drools Policy
|
||||
|
||||
The Authorization Services Drools Policy has been removed.
|
||||
|
||||
|
|
@ -1,115 +0,0 @@
|
|||
== RH SSO 7.5
|
||||
|
||||
The following changes have occurred from {project_name} 7.4 to {project_name} 7.5.
|
||||
|
||||
=== Upgrade to EAP 7.4
|
||||
|
||||
The {project_name} server was upgraded to use EAP 7.4 as the underlying container. This change does not directly involve any specific {project_name} server functionality, but a few changes relate to the migration.
|
||||
|
||||
==== Dependency updates
|
||||
|
||||
The dependencies were updated to the versions used by EAP 7.4 server. For example, the Infinispan component version is now 11.0.
|
||||
|
||||
==== Configuration changes
|
||||
|
||||
There are a few configuration changes in the standalone(-ha).xml and domain.xml files. You should follow the <<_install_new_version>> section to handle the migration of configuration files automatically.
|
||||
|
||||
==== SmallRye manual changes
|
||||
Manual changes are required when standalone.xml contains references to SmallRye modules. These modules were removed from the underlying {appserver_name} distribution, and the server does not start if the configuration references them. The server configuration migration via `migrate-standalone.cli` fails before any changes are made to the configuration.
|
||||
|
||||
To correct this problem, remove all the lines that refer to SmallRye modules. In the default configuration, you need to remove specifically the following lines:
|
||||
|
||||
[source,xml]
|
||||
<extension module="org.wildfly.extension.microprofile.config-smallrye"/>
|
||||
<extension module="org.wildfly.extension.microprofile.health-smallrye"/>
|
||||
<extension module="org.wildfly.extension.microprofile.metrics-smallrye"/>
|
||||
|
||||
[source,xml]
|
||||
<subsystem xmlns="urn:wildfly:microprofile-config-smallrye:1.0"/>
|
||||
<subsystem xmlns="urn:wildfly:microprofile-health-smallrye:2.0" security-enabled="false" empty-liveness-checks-status="${env.MP_HEALTH_EMPTY_LIVENESS_CHECKS_STATUS:UP}" empty-readiness-checks-status="${env.MP_HEALTH_EMPTY_READINESS_CHECKS_STATUS:UP}"/>
|
||||
<subsystem xmlns="urn:wildfly:microprofile-metrics-smallrye:2.0" security-enabled="false" exposed-subsystems="*" prefix="${wildfly.metrics.prefix:wildfly}"/>
|
||||
|
||||
==== Cross-Datacenter replication changes
|
||||
|
||||
* You will need to upgrade {jdgserver_name} server to version {jdgserver_version_latest}. The older version may still work, but it is not guaranteed as it is no longer tested.
|
||||
|
||||
* We recommend that you use the `protocolVersion` property added to the remote-store element when configuring Infinispan caches. When connecting to the {jdgserver_name} server {jdgserver_version_latest}, the recommended version of the hotrod protocol version is 2.9. The Infinispan library version differs among {project_name} server and {jdgserver_name} server. For more details, see the Cross-Datacenter documentation.
|
||||
|
||||
* We recommend that you use `remoteStoreSecurityEnabled` property under the `connectionsinfinispan` subsystem. For more details, see the Cross-Datacenter documentation.
|
||||
|
||||
=== UserModel Migration
|
||||
The `UserModel` includes certain fields, `username`, `email`, `firstName` and `lastName`, which are now converted to custom attributes. This change was made to prepare for adding more sophisticated user profiles to {project_name} in an upcoming version.
|
||||
|
||||
NOTE: If a database contains users with custom attributes of that exact name, these attributes will no longer be read from the database and may be deleted. Therefore, before upgrading to RH SSO 7.5, rename any custom attribute that matches one of these names.
|
||||
|
||||
This situation implies that the `username` can now also be accessed and set by `UserModel.getFirstAttribute(UserModel.USERNAME)`. Similar implications exist for other fields. Implementors of SPIs subclassing the `UserModel` directly or indirectly should ensure that the behavior between `setUsername` and `setSingleAttribute(UserModel.USERNAME, ...)` (and similar for the other fields) is consistent.
|
||||
|
||||
Users of the policy evaluation feature should adapt their policies if they use the number of attributes in their evaluations. Every user will now have four new attributes by default.
|
||||
|
||||
The public API of `UserModel` did not change. No changes to frontend resources or SPIs accessing user data are necessary. Also, the database did not change yet.
|
||||
|
||||
=== Upgrade to PatternFly 4
|
||||
|
||||
The {project_name} login theme components have been upgraded to PatternFly 4.
|
||||
The old PatternFly 3 runs simultaneously with the new one, so it's possible to keep PF3 components.
|
||||
|
||||
However, some changes to the design of the login theme were performed. Please upgrade your custom login theme to the new version. An example with the necessary changes can be found in the `examples/themes/theme/sunrise` directory. No additional setup is required.
|
||||
|
||||
=== New API for Instagram IdP
|
||||
|
||||
Instagram IdP now uses a new API. The old legacy API was *deprecated*. This change requires new API credentials. For details, please refer to the link:{adminguide_link}#instagram[{adminguide_name}].
|
||||
|
||||
For users who use Instagram IdP to log into Instagram, those users need a different authentication method, such as a password. They can log in to manually update their Instagram social links or create a new account in {project_name}. This restriction exists because Instagram user IDs in the previous API are incompatible with the new API. However the new API temporarily returns both new and old user IDs to allow migration. {project_name} automatically migrates the ID once the user logs in.
|
||||
|
||||
=== Valid Request URIs for SSRF protection
|
||||
If you use the OpenID Connect parameter `request_uri`, your client needs to have `Valid Request URIs` configured to protect against SSRF attacks
|
||||
|
||||
You can configure this feature through the Admin Console on the client details page, or through the admin REST API or client registration API. Valid Request URIs need to contain the list of Request URI values that are permitted for the particular client.
|
||||
|
||||
You could instead use wildcards or relative paths, such as the `Valid Redirect URIs` option. However, we recommend using as specific value as possible for security purposes.
|
||||
|
||||
=== Read-only user attributes
|
||||
Read-only user attributes are now available. Some of these user attributes are not to be edited by the user or administrator when updating users with the REST API or with the {project_name} user interfaces. In particular, this change is important when you use any of the following:
|
||||
|
||||
* Custom user storage providers
|
||||
* Custom authenticators
|
||||
* Custom JavaScript authorization policies that establish authorization based on a user attribute
|
||||
* X.509 authenticator with a custom attribute for mapping the X.509 certificate to the user identity
|
||||
* Any other custom functionality where some of the user attributes are used as the metadata for storing authentication/authorization/identity context rather than simple user profile information.
|
||||
|
||||
For more details, see the link:{adminguide_link}#read_only_user_attributes[Threat model mitigation chapter].
|
||||
|
||||
=== No user session needed after Docker authentication
|
||||
No user session is created after successful authentication with the Docker protocol. For details, please refer to the link:{adminguide_link}#_docker[{adminguide_name}].
|
||||
|
||||
=== Client Credentials Grant without default refresh token
|
||||
For this {project_name} version, the OAuth2 Client Credentials Grant endpoint does not issue refresh tokens by default. This behavior is aligned with the OAuth2 specification.
|
||||
|
||||
As a result, no user session is created on the {project_name} server side after successful Client Credentials authentication. The result is improved performance and memory consumption. Clients that use Client Credentials Grant are encouraged to stop using refresh tokens and instead authenticate at every request with `grant_type=client_credentials` instead of using `refresh_token` as grant type.
|
||||
|
||||
In relation to this, {project_name} supports revocation of access tokens in the OAuth2 Revocation Endpoint. Therefore, clients are allowed to revoke individual access tokens if needed.
|
||||
|
||||
For backwards compatibility, you could stay with the previous version’s behavior. With that approach, the refresh token is still issued after a successful authentication with the Client Credentials Grant and also the user session is created. For a particular client, you can enable the previous behavior in the Admin Console as follows:
|
||||
|
||||
.Procedure
|
||||
|
||||
. Click *Clients* in the menu.
|
||||
. Click the client you want to modify.
|
||||
. Expand the *OpenID Connect Compatibility Modes* section.
|
||||
. Toggle *Use Refresh Tokens For Client Credentials Grant* to *ON*.
|
||||
. Click *Save.*
|
||||
|
||||
=== Non-standard token introspection endpoint removed
|
||||
In previous versions, {project_name} advertised two introspection endpoints: `token_introspection_endpoint` and `introspection_endpoint`.
|
||||
The latter is the one defined by https://datatracker.ietf.org/doc/html/rfc8414#section-2[RFC-8414]. The former was deprecated
|
||||
and is now removed.
|
||||
|
||||
=== LDAP no-import fix
|
||||
In the previous {project_name} version, when the LDAP provider was configured with `Import Users` OFF, it was possible to update the user even if some non-LDAP mapped attributes were changed. This situation resulted in confusing behavior. The attribute appeared to be updated, but it was not updated.
|
||||
|
||||
For example, if you had tried to update a user with the admin REST API and the user had some incorrect attribute changes, the update was possible. With the
|
||||
current version, the update is not possible and you are immediately informed about the reason.
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
@ -1,171 +0,0 @@
|
|||
== RH SSO 7.6
|
||||
|
||||
The following changes have occurred from {project_name} 7.5 to {project_name} 7.6.
|
||||
|
||||
=== Step-up authentication
|
||||
|
||||
Step-up authentication is a new feature. This feature provides the `acr` client scope, which contains a protocol mapper that is supposed to add the `acr`
|
||||
claim in the token. The `acr` claim is not added automatically now as it was before this version, but it is added with the usage
|
||||
of this client scope and protocol mapper.
|
||||
|
||||
The client scope is added as a realm "default" client scope and hence will be added to all newly created clients. For performance reasons,
|
||||
the client scope is not automatically added to all existing clients during migration. The clients will not have an `acr` claim by default after
|
||||
the migration. Consider these possible actions:
|
||||
|
||||
- If you do not plan to use step-up authentication feature, but you rely on the `acr` claim in the token, you can disable `step_up_authentication`
|
||||
feature. The claim will be added with the value `1` in case of normal authentication and `0` in case of SSO authentication.
|
||||
- Add `acr` client scope to your clients manually by admin REST API or admin console. This is needed especially if you want to use step-up authentication.
|
||||
If you have a large number of clients in the realm and want to use `acr` claim for all of them, you can trigger some SQL similar to this against your DB.
|
||||
However, remember to clear the cache or restart the server if {project_name} is already started:
|
||||
|
||||
```
|
||||
insert into CLIENT_SCOPE_CLIENT (CLIENT_ID, SCOPE_ID, DEFAULT_SCOPE) select CLIENT.ID as CLIENT_ID, CLIENT_SCOPE.ID as SCOPE_ID, true as DEFAULT_SCOPE
|
||||
from CLIENT_SCOPE, CLIENT where CLIENT_SCOPE.REALM_ID='test' and CLIENT_SCOPE.NAME='acr' and CLIENT.REALM_ID='test' and CLIENT.PROTOCOL='openid-connect';
|
||||
```
|
||||
|
||||
=== OpenID Connect Logout
|
||||
|
||||
Previous versions of {project_name} had supported automatic logout of the user and redirecting to the application by opening logout endpoint URL such as
|
||||
`http(s)://example-host/auth/realms/my-realm-name/protocol/openid-connect/logout?redirect_uri=encodedRedirectUri`. While that implementation was easy to use, it had potentially negative impact
|
||||
on performance and security. The new version has better support for logout based on the OpenID Connect RP-Initiated Logout specification. The parameter `redirect_uri` is no longer supported; also,
|
||||
in the new version, the user needs to confirm the logout. It is possible to omit the confirmation and do automatic redirect to the application when you include parameter `post_logout_redirect_uri`
|
||||
together with the parameter `id_token_hint` with the ID Token used for login.
|
||||
|
||||
The existing deployments are affected in the following ways:
|
||||
|
||||
- If your application directly uses links to logout endpoint with the `redirect_uri` parameter, you may be required to change this as described above.
|
||||
Consider either removing the `redirect_uri` parameter entirely or replacing it with the `id_token_hint` and `post_logout_redirect_uri` parameters.
|
||||
- If you use java adapters and your application does logout by call `httpServletRequest.logout()`, you are not affected because this call uses the backchannel variant of the logout endpoint
|
||||
and that one was not changed.
|
||||
- If you use the latest javascript adapter, you are also not affected. However if your application uses an older version of the JavaScript adapter, you are affected as this
|
||||
adapter uses the variant of the logout endpoint with the deprecated `redirect_uri` parameter. In this case, you may need to upgrade to the latest version of the JavaScript adapter.
|
||||
- For the Node.js adapter, the same guideline applies as for the JavaScript adapter. You are encouraged to update to the latest version as the older version of the adapter uses the deprecated `redirect_uri` parameter.
|
||||
With the latest Node.js adapter, you are not affected as long as you use the logout based on the `/logout` URL as described in the documentation or in the Node.js adapter example. However, in the case
|
||||
when your application directly uses the method `keycloak.logoutUrl`, you can consider adding `idTokenHint` as the second argument to this method. The possibility to add `idTokenHint` as second argument was newly
|
||||
added in this version. The `idTokenHint` needs to be a valid ID Token that was obtained during the login. Adding `idTokenHint` is optional, but if you omit it, your users will need to confirm the logout screen as
|
||||
described earlier. Also they will not be redirected back to the application after logout.
|
||||
|
||||
There is a backwards compatibility option, which allows your application to still use the old format of the `redirect_uri` parameter.
|
||||
|
||||
You can enable this parameter by including the following configuration in the `standalone-*.xml` file
|
||||
|
||||
[source,bash,subs=+attributes]
|
||||
----
|
||||
<spi name="login-protocol">
|
||||
<provider name="openid-connect" enabled="true">
|
||||
<properties>
|
||||
<property name="legacy-logout-redirect-uri" value="true"/>
|
||||
</properties>
|
||||
</provider>
|
||||
</spi>
|
||||
----
|
||||
|
||||
With this configuration, you can still use the format with the `redirect_uri` parameter. Note the confirmation screen will be needed if the `id_token_hint` is omitted.
|
||||
|
||||
WARNING: The backwards compatibility switch will be removed in some future version. You are encouraged to update your clients as soon as possible
|
||||
as described above rather than rely on this switch.
|
||||
|
||||
=== Removal of the `upload-scripts` feature
|
||||
|
||||
Previous versions of {project_name} had supported managing JavaScript code through the management interfaces like the administrations console and REST API. Starting from this version
|
||||
this is no longer possible, and you should now deploy your scripts to the server in order to configure the following providers:
|
||||
|
||||
* OpenID Connect Script Mapper
|
||||
* Script Authenticator (Authentication Execution)
|
||||
* JavaScript Policies
|
||||
|
||||
More details about how to deploy scripts to the server are available in the https://www.keycloak.org/docs/latest/server_development/#_script_providers[documentation]. Note that to use scripts, you are still
|
||||
required to enable the `scripts` technology preview feature.
|
||||
|
||||
```
|
||||
./standalone.sh -Dkeycloak.profile=preview
|
||||
```
|
||||
When deploying scripts, the server is going to automatically create their corresponding providers so that you can select them when configuring authentication flows, mappers, and authorization policies.
|
||||
|
||||
In general, the steps to update your realms are the following:
|
||||
|
||||
* Before upgrading, remove any script provider you are using.
|
||||
* After the upgrade, deploy your scripts following the instructions in the https://www.keycloak.org/docs/latest/server_development/#_script_providers[documentation].
|
||||
* Update your authentication flows, mappers, and the client authorization settings to use the providers created from the scripts deployed to the server.
|
||||
|
||||
=== Account console Patternfly upgrade
|
||||
|
||||
The Patternfly (PF) React libraries have been updated, `@patternfly/react-core` from v3.153.3 to v4.147.0, `@patternfly/react-icons` from v3.15.16 to v 4.11.8, and `@patternfly/react-styles` from v3.7.14 to v4.11.8. Several minor UI updates were made to bring the account console into alignment with PF design standards.
|
||||
|
||||
Custom developed account UIs might not be compatible with these updates due to the breaking changes in PF. Most breaking changes should be resolvable by updating props on PF components.
|
||||
|
||||
Resources:
|
||||
|
||||
- [Patternfly docs](https://www.patternfly.org)
|
||||
|
||||
|
||||
Components known to have breaking changes:
|
||||
|
||||
- Alert
|
||||
|
||||
- `action` prop changed to `actionClose`
|
||||
|
||||
- Expandable
|
||||
|
||||
- renamed to `ExpandableSection`
|
||||
|
||||
- Title
|
||||
|
||||
- size attr now uses `TitleSizes`
|
||||
|
||||
- DataListContent
|
||||
|
||||
- `noPadding` changed to `hasNoPadding`
|
||||
|
||||
- Grid, Stack, Level, Gallery
|
||||
|
||||
- `gutter` attr changed to `hasGutter`
|
||||
|
||||
- Modal
|
||||
|
||||
- sizing control changed from, e.g. `isLarge`, to use `ModalVariant`, e.g. `variant={ModalVariant.large}`
|
||||
|
||||
- Select
|
||||
|
||||
- `ariaLabelTypeAhead` to `typeAheadAriaLabel`
|
||||
|
||||
- `isExpanded` to `isOpen`
|
||||
|
||||
- `ariaLabelledBy` to `aria-labelledby`
|
||||
|
||||
- DataListContent
|
||||
|
||||
- `noPadding` to `hasNoPadding`
|
||||
|
||||
=== Client Policies Migration : client-scopes
|
||||
|
||||
If you used a policy including client-scopes condition and edited JSON document directly, you will need to change the "scope" field name in a JSON document to "scopes".
|
||||
|
||||
=== Liquibase upgraded to version 4.6.2
|
||||
|
||||
Liquibase was updated from version 3.5.5 to 4.6.2, which includes, among other things, several bug fixes, and a new way of registering custom extensions using `ServiceLoader`.
|
||||
|
||||
Closely follow the <<_upgrading,Upgrading Guide>>, specifically of *backing up
|
||||
existing database before upgrade*. While we did our best to test the consequences of the Liquibase upgrade, some installations could be using specific setup unknown to us.
|
||||
|
||||
=== Deprecated features in the {project_operator}
|
||||
|
||||
With this release, we have deprecated `podDisruptionBudget` field in the Keycloak CR of {project_operator}.
|
||||
This optional field will be ignored when the Operator is deployed on OCP 4.12 and higher versions.
|
||||
|
||||
As a workaround, you can manually create the Pod Disruption Budget in your cluster, for example:
|
||||
```yaml
|
||||
apiVersion: policy/v1
|
||||
kind: PodDisruptionBudget
|
||||
metadata:
|
||||
labels:
|
||||
app: keycloak
|
||||
name: keycloak
|
||||
spec:
|
||||
maxUnavailable: 1
|
||||
selector:
|
||||
matchLabels:
|
||||
component: keycloak
|
||||
```
|
||||
See also the https://kubernetes.io/docs/tasks/run-application/configure-pdb/[Kubernetes Documentation].
|
||||
|
||||
|
|
@ -1,12 +0,0 @@
|
|||
[id="release_changes"]
|
||||
|
||||
== Release-specific changes
|
||||
|
||||
Review these changes carefully before upgrading.
|
||||
|
||||
include::changes-76.adoc[leveloffset=1]
|
||||
include::changes-75.adoc[leveloffset=1]
|
||||
include::changes-74.adoc[leveloffset=1]
|
||||
include::changes-73.adoc[leveloffset=1]
|
||||
include::changes-72.adoc[leveloffset=1]
|
||||
include::changes-71.adoc[leveloffset=1]
|
||||
|
|
@ -1,60 +0,0 @@
|
|||
[[intro]]
|
||||
|
||||
== Upgrading Red Hat Single Sign-On
|
||||
|
||||
Red Hat Single Sign-On (RH-SSO) {project_versionDoc} is based on the Keycloak project and provides security for your web applications by
|
||||
providing Web single sign-on capabilities based on popular standards such as SAML 2.0, OpenID Connect, and OAuth 2.0.
|
||||
The Red Hat Single Sign-On Server can act as a SAML or OpenID Connect-based identity provider, mediating with your
|
||||
enterprise user directory or third-party SSO provider for identity information and your applications using standards-based
|
||||
tokens.
|
||||
|
||||
RH-SSO provides two operating modes: standalone server or managed domain. The standalone server operating mode represents
|
||||
running RH-SSO as a single server instance. The managed domain operating mode allows for the management of multiple
|
||||
RH-SSO instances from a single control point. The upgrade process differs depending on which operating mode has been
|
||||
implemented. Specific instructions for each mode are provided where applicable.
|
||||
|
||||
The purpose of this guide is to document the steps that are required to successfully upgrade from
|
||||
Red Hat Single Sign-On 7.x to Red Hat Single Sign-On {project_versionDoc}.
|
||||
|
||||
=== About upgrades
|
||||
|
||||
Depending on your version of RH-SSO, you choose one of three types of upgrade. However, if you starting from Keycloak, you choose xref:keycloak-migration[this procedure].
|
||||
|
||||
==== Major upgrades
|
||||
|
||||
A major upgrade or migration is required when RH-SSO is upgraded from one major release to another, for example, from
|
||||
Red Hat Single Sign-On 7.2 to Red Hat Single Sign-On 8.0. There may be breaking API changes between major releases
|
||||
that could require rewriting parts of applications or server extensions.
|
||||
|
||||
==== Minor updates
|
||||
|
||||
Red Hat Single Sign-On periodically provides point releases, which are minor updates that include bug fixes, security
|
||||
fixes, and new features. If you plan to upgrade from one Red Hat Single Sign-On point release to another, for example,
|
||||
from Red Hat Single Sign-On 7.3 to Red Hat Single Sign-On {project_versionDoc}, code changes should not be required for applications or
|
||||
custom server extensions as long as no private, unsupported, or tech preview APIs are used.
|
||||
|
||||
==== Micro updates
|
||||
|
||||
Red Hat Single Sign-On {project_versionDoc} also periodically provides micro releases that contain bug and security fixes.
|
||||
Micro releases increment the minor release version by the last digit, for example from {project_versionDoc}.0 to {project_versionDoc}.1. These releases
|
||||
do not require migration and should not impact the server configuration files. The patch management system for ZIP
|
||||
installations can also roll back the patch and server configuration.
|
||||
|
||||
A micro release only contains the artifacts that have changed. For example if Red Hat Single Sign-On {project_versionDoc}.1 contains changes to
|
||||
the server and the JavaScript adapter, but not the EAP adapter, only the server and JavaScript adapter are released and require
|
||||
updating.
|
||||
|
||||
[id="keycloak-migration"]
|
||||
=== Migrating Keycloak to RH-SSO
|
||||
|
||||
You can migrate to Red Hat Single Sign-On, the supported Red Hat product, from Keycloak, the community project.
|
||||
|
||||
.Prerequisites
|
||||
|
||||
* To learn about new features before the upgrade, review the xref:release_changes[changes].
|
||||
* Verify that you have installed the correct version of Keycloak as a starting point. To migrate to Red Hat Single Sign-On {project_versionDoc}, first install Keycloak {keycloak_upgrade_version}.
|
||||
|
||||
.Procedure
|
||||
|
||||
. Perform the xref:_upgrading_minor[Minor Upgrades] procedure. Although this procedure is labelled *Minor Upgrade*, the same steps apply for this migration.
|
||||
. Perform the xref:_upgrade_adapters[Adapter Upgrade procedure].
|
||||
|
|
@ -1,25 +0,0 @@
|
|||
===== Theme changes RH-SSO 7.1
|
||||
|
||||
**Templates**
|
||||
|
||||
* Account: account.ftl
|
||||
* Account: federatedIdentity.ftl
|
||||
* Account: totp.ftl
|
||||
* Login: info.ftl
|
||||
* Login: login-config-totp.ftl
|
||||
* Login: login-reset-password.ftl
|
||||
* Login: login.ftl
|
||||
|
||||
**Messages**
|
||||
|
||||
* Account: editAccountHtmlTtile renamed to editAccountHtmlTitle
|
||||
* Account: role_uma_authorization added
|
||||
* Login: loginTotpStep1 value changed
|
||||
* Login: invalidPasswordGenericMessage added
|
||||
* Login: invlidRequesterMessage renamed to invalidRequesterMessage
|
||||
* Login: clientDisabledMessage added
|
||||
|
||||
**Styles**
|
||||
|
||||
* Account: account.css
|
||||
* Login: login.css
|
||||
|
|
@ -1,51 +0,0 @@
|
|||
===== Theme changes RH-SSO 7.2
|
||||
|
||||
**Templates**
|
||||
|
||||
* Account: account.ftl
|
||||
* Account: applications.ftl
|
||||
* Account: federatedIdentity.ftl
|
||||
* Account: password.ftl
|
||||
* Account: sessions.ftl
|
||||
* Account: template.ftl
|
||||
* Account: totp.ftl
|
||||
* Admin: index.ftl
|
||||
* Email: email-test.ftl (new)
|
||||
* Email: email-verification.ftl
|
||||
* Email: event-login_error.ftl
|
||||
* Email: event-removed_totp.ftl
|
||||
* Email: event-update_password.ftl
|
||||
* Email: event-update_totp.ftl
|
||||
* Email: executeActions.ftl
|
||||
* Email: identity-provider-link.ftl
|
||||
* Email: password-reset.ftl
|
||||
* Login: bypass_kerberos.ftl (removed)
|
||||
* Login: error.ftl
|
||||
* Login: info.ftl
|
||||
* Login: login-config-totp.ftl
|
||||
* Login: login-idp-link-email.ftl
|
||||
* Login: login-oauth-grant.ftl
|
||||
* Login: login-page-expired.ftl (new)
|
||||
* Login: login-reset-password.ftl
|
||||
* Login: login-totp.ftl
|
||||
* Login: login-update-password.ftl
|
||||
* Login: login-update-profile.ftl
|
||||
* Login: login-verify-email.ftl
|
||||
* Login: login-x509-info.ftl (new)
|
||||
* Login: login.ftl (new)
|
||||
* Login: register.ftl (new)
|
||||
* Login: template.ftl (new)
|
||||
* Login: terms.ftl (new)
|
||||
|
||||
**Messages**
|
||||
|
||||
* Account: messages_en.properties
|
||||
* Admin: admin-messages_en.properties
|
||||
* Admin: messages_en.properties
|
||||
* Email: messages_en.properties
|
||||
* Login: messages_en.properties
|
||||
|
||||
**Styles**
|
||||
|
||||
* Account: account.css
|
||||
* Login: login.css
|
||||
|
|
@ -1,59 +0,0 @@
|
|||
===== Theme changes RH-SSO 7.3
|
||||
|
||||
**Templates**
|
||||
|
||||
* Account: account.ftl
|
||||
* Account: applications.ftl
|
||||
* Account: resource-detail.ftl (new)
|
||||
* Account: resources.ftl (new)
|
||||
* Account: template.ftl
|
||||
* Account: totp.ftl
|
||||
* Email-html: email-test.ftl
|
||||
* Email-html: email-verification-with-code.ftl (new)
|
||||
* Email-html: email-verification.ftl
|
||||
* Email-html: event-login_error.ftl
|
||||
* Email-html: event-removed_totp.ftl
|
||||
* Email-html: event-update_password.ftl
|
||||
* Email-html: event-update_totp.ftl
|
||||
* Email-html: executeActions.ftl
|
||||
* Email-html: identity-provider-link.ftl
|
||||
* Email-html: password-reset.ftl
|
||||
* Email-text: email-verification-with-code.ftl (new)
|
||||
* Email-text: email-verification.ftl
|
||||
* Email-text: executeActions.ftl
|
||||
* Email-text: identity-provider-link.ftl
|
||||
* Email-text: password-reset.ftl
|
||||
* Login: cli_splash.ftl (new)
|
||||
* Login: code.ftl
|
||||
* Login: error.ftl
|
||||
* Login: info.ftl
|
||||
* Login: login-config-totp-text.ftl (new)
|
||||
* Login: login-config-totp.ftl
|
||||
* Login: login-idp-link-confirm.ftl
|
||||
* Login: login-idp-link-email.ftl
|
||||
* Login: login-oauth-grant.ftl
|
||||
* Login: login-page-expired.ftl
|
||||
* Login: login-reset-password.ftl
|
||||
* Login: login-totp.ftl
|
||||
* Login: login-update-password.ftl
|
||||
* Login: login-update-profile.ftl
|
||||
* Login: login-verify-email-code-text.ftl (new)
|
||||
* Login: login-verify-email.ftl
|
||||
* Login: login-x509-info.ftl
|
||||
* Login: login.ftl
|
||||
* Login: register.ftl
|
||||
* Login: template.ftl
|
||||
* Login: terms.ftl
|
||||
* Welcome: index.ftl (new)
|
||||
|
||||
**Messages**
|
||||
|
||||
* Account: messages_en.properties
|
||||
* Admin: admin-messages_en.properties
|
||||
* Email: messages_en.properties
|
||||
* Login: messages_en.properties
|
||||
|
||||
**Styles**
|
||||
|
||||
* Login: login-rhsso.css (new)
|
||||
* Welcome: welcome-rhsso.css
|
||||
|
|
@ -1,20 +0,0 @@
|
|||
[[rpm-patching]]
|
||||
= Patching an RPM Installation
|
||||
|
||||
.Prerequisites
|
||||
* Ensure that the base operating system is up-to-date, and is subscribed and enabled to get updates from the standard Red Hat Enterprise Linux repositories.
|
||||
* Ensure that you are subscribed to the relevant RH-SSO repository for the update.
|
||||
* Back up all configuration files, deployments, and user data.
|
||||
|
||||
[IMPORTANT]
|
||||
====
|
||||
For a managed domain, the RH-SSO domain controller should be updated first.
|
||||
====
|
||||
|
||||
To install a RH-SSO patch via RPM from your subscribed repository, update your Red Hat Enterprise Linux system using the following command:
|
||||
|
||||
[source,bash,options="nowrap"]
|
||||
----
|
||||
yum update
|
||||
----
|
||||
|
||||
|
|
@ -1,163 +0,0 @@
|
|||
[[zip-patching]]
|
||||
= ZIP/installer installation patching
|
||||
|
||||
Patches for a ZIP installation of RH-SSO are available to download from the
|
||||
link:https://access.redhat.com/[Red Hat Customer Portal].
|
||||
|
||||
For multiple RH-SSO hosts in a managed domain environment, individual hosts can be patched from your RH-SSO domain controller.
|
||||
|
||||
In addition to applying a patch, you can also roll back the application of a patch.
|
||||
|
||||
== Important notes on ZIP installation patching
|
||||
|
||||
* If you apply a patch that updates a module, the new patched JARs that are used at runtime are stored in `RHSSO_HOME/modules/system/layers/base/.overlays/_PATCH_ID_/_MODULE_`. The original unpatched files are left in `RHSSO_HOME/modules/system/layers/base/_MODULE_`, but these JARs are *not* used at runtime.
|
||||
* In order to significantly decrease the size of cumulative patch releases for RH-SSO 7 you cannot perform a partial roll back of a cumulative patch. For a patch that has been applied, you will only be able to roll back the whole patch.
|
||||
+
|
||||
For example, if you apply CP03 to RH-SSO 7.0.0, you will not be able to roll back to CP01 or CP02. If you would like the ability to roll back to each cumulative patch release, each cumulative patch must be applied separately in the order they were released.
|
||||
|
||||
== Applying a patch
|
||||
|
||||
NOTE: RH-SSO servers that have been installed using the RPM method cannot be updated using these instructions. See the xref:rpm-patching[RPM instructions for applying a patch] instead.
|
||||
|
||||
You can apply downloaded patches to a RH-SSO server using either the xref:zip_patching_management_cli[management CLI] or the xref:zip_patching_management_console[management console].
|
||||
|
||||
[[zip_patching_management_cli]]
|
||||
.Applying a patch to RH-SSO using the management CLI
|
||||
|
||||
.Procedure
|
||||
. Download the patch file from the Red Hat Customer Portal at https://access.redhat.com/downloads/.
|
||||
|
||||
. From the link:{appserver_managementcli_link}[management CLI], apply the patch using the following command, including the appropriate path to the patch file:
|
||||
+
|
||||
[options="nowrap"]
|
||||
----
|
||||
patch apply /path/to/downloaded-patch.zip
|
||||
----
|
||||
+
|
||||
[NOTE]
|
||||
====
|
||||
To patch another RH-SSO host in a managed domain, you can specify the RH-SSO host name using the `--host=` argument. For example:
|
||||
|
||||
[options="nowrap"]
|
||||
----
|
||||
patch apply /path/to/downloaded-patch.zip --host=my-host
|
||||
----
|
||||
====
|
||||
+
|
||||
The patch tool will warn if there are any conflicts in attempting to apply the patch. If there are conflicts, enter `patch --help` for the available arguments to re-run the command with an argument specifying how to resolve the conflicts.
|
||||
|
||||
. Restart the RH-SSO server for the patch to take effect:
|
||||
+
|
||||
[options="nowrap"]
|
||||
----
|
||||
shutdown --restart=true
|
||||
----
|
||||
|
||||
[[zip_patching_management_console]]
|
||||
.Applying a patch to RH-SSO using the Management Console
|
||||
|
||||
.Procedure
|
||||
|
||||
. Download the patch file from the Red Hat Customer Portal at https://access.redhat.com/downloads/.
|
||||
. Open the link:{appserver_managementconsole_link}[management console] and navigate to the *Patch Management* view.
|
||||
.. For a standalone server, click the *Patching* tab.
|
||||
+
|
||||
.The Patch Management Screen for a Standalone Server
|
||||
image:images/patching-standalone-tab.png[The Patch Management Screen for a Standalone Server]
|
||||
.. For a server in a managed domain, click the *Patching* tab, then select the host that you want to patch from the table, and click *View*.
|
||||
+
|
||||
.The Patch Management Screen for a Managed Domain
|
||||
image:images/patching-domain-tab.png[The Patch Management Screen for a Managed Domain]
|
||||
|
||||
. Click *Apply a New Patch*.
|
||||
.. If you are patching a managed domain host, on the next screen select whether to shut down the servers on the host, and click *Next*.
|
||||
|
||||
. Click the *Browse* button, select the downloaded patch you want to apply, and then click *Next*.
|
||||
+
|
||||
.Apply Patch Screen
|
||||
image:images/patching-select-patch.png[Apply Patch Screen]
|
||||
.. If there are any conflicts in attempting to apply the patch, a warning will be displayed. Click *View error details* to see the detail of the conflicts. If there is a conflict, you can either cancel the operation, or select the *Override all conflicts* check box and click *Next*. Overriding conflicts will result in the content of the patch overriding any user modifications.
|
||||
|
||||
. After the patch has been successfully applied, select whether to restart RH-SSO now for the patch to take effect, and click *Finish*.
|
||||
|
||||
== Rolling back a patch
|
||||
|
||||
You can roll back a previously applied RH-SSO patch using either the xref:zip_rollback_management_cli[management CLI] or the xref:zip_rollback_management_console[management console].
|
||||
|
||||
IMPORTANT: Rolling back a patch using the patch management system is not intended as a general uninstall functionality. It is only intended to be used immediately after the application of a patch that had undesirable effects.
|
||||
|
||||
.Prerequisites
|
||||
* A patch that was previously applied.
|
||||
|
||||
[WARNING]
|
||||
====
|
||||
When following either procedure, use caution when specifying the value of the `Reset Configuration` option:
|
||||
|
||||
If set to `TRUE`, the patch rollback process will also roll back the RH-SSO server configuration files to their pre-patch state. Any changes that were made to the RH-SSO server configuration files after the patch was applied will be lost.
|
||||
|
||||
If set to `FALSE`, the server configuration files will not be rolled back. In this situation, it is possible that the server will not start after the rollback, as the patch may have altered configurations, such as namespaces, which may no longer be valid and will have to be fixed manually.
|
||||
====
|
||||
|
||||
[[zip_rollback_management_cli]]
|
||||
.Rolling Back a Patch Using the Management CLI
|
||||
|
||||
.Procedure
|
||||
|
||||
. From the management CLI, use the `patch history` command to find the ID of the patch that you want to roll back.
|
||||
+
|
||||
--
|
||||
NOTE: If you are using a managed domain, you must add the `--host=_HOSTNAME_` argument to the commands in this procedure to specify the RH-SSO host.
|
||||
--
|
||||
|
||||
. Roll back the patch with the appropriate patch ID from the previous step.
|
||||
+
|
||||
[options="nowrap"]
|
||||
----
|
||||
patch rollback --patch-id=PATCH_ID --reset-configuration=TRUE
|
||||
----
|
||||
+
|
||||
The patch tool will warn if there are any conflicts in attempting to roll back the patch. If there are conflicts, enter `patch --help` for the available arguments to re-run the command with an argument specifying how to resolve the conflicts.
|
||||
|
||||
. Restart the RH-SSO server for the patch roll back to take effect:
|
||||
+
|
||||
[options="nowrap"]
|
||||
----
|
||||
shutdown --restart=true
|
||||
----
|
||||
|
||||
[[zip_rollback_management_console]]
|
||||
.Rolling back a patch using the Management Console
|
||||
|
||||
.Procedure
|
||||
. Open the management console and navigate to the *Patch Management* view.
|
||||
.. For a standalone server, click the *Patching* tab.
|
||||
.. For a server in a managed domain, click the *Patching* tab, then select the host that you want to patch from the table, and click *View*.
|
||||
|
||||
. Select the patch that you want to rollback from those listed in the table, then click *Rollback*.
|
||||
+
|
||||
.Recent Patch History Screen
|
||||
image:images/patching-rollback-table.png[Recent Patch History Screen]
|
||||
.. If you are rolling back a patch on a managed domain host, on the next screen select whether to shut down the servers on the host, and click *Next*.
|
||||
|
||||
. Choose your options for the rollback process, then click *Next*.
|
||||
+
|
||||
.Patch Rollback Options
|
||||
image:images/patching-rollback-options.png[Patch Rollback Options]
|
||||
|
||||
. Confirm the options and the patch to be rolled back, then click *Next*.
|
||||
.. If there are any conflicts in attempting to roll back the patch and the *Override all* option was not selected, a warning will be displayed. Click *View error details* to see the detail of the conflicts. If there is a conflict, you can either cancel the operation, or click *Choose Options* and try the operation again with the *Override all* check box selected. Overriding conflicts will result in the rollback operation overriding any user modifications.
|
||||
|
||||
. After the patch has been successfully rolled back, select whether to restart the RH-SSO server now for the changes to take effect, and click *Finish*.
|
||||
|
||||
== Clearing patch history
|
||||
|
||||
When patches are applied to a RH-SSO server, the content and history of the patches are preserved for use in rollback operations. If multiple cumulative patches are applied, the patch history may use a significant amount of disk space.
|
||||
|
||||
You can use the following management CLI command to remove all older patches that are not currently in use. When using this command, only the latest cumulative patch is preserved along with the GA release. This is only useful for freeing space if multiple cumulative patches have previously been applied.
|
||||
|
||||
[options="nowrap"]
|
||||
----
|
||||
/core-service=patching:ageout-history
|
||||
----
|
||||
|
||||
IMPORTANT: If you clear the patch history, you will not be able to roll back a previously applied patch.
|
||||
|
|
@ -1,25 +0,0 @@
|
|||
[[_patching_js_adapter]]
|
||||
==== Patching the JavaScript adapter
|
||||
|
||||
There are no patching mechanism available for the JavaScript adapter and this is distributed as a complete new download.
|
||||
|
||||
.Procedure
|
||||
|
||||
To upgrade a JavaScript adapter that has been copied to your web application, complete the following steps:
|
||||
|
||||
. Download the new archive.
|
||||
. Overwrite the keycloak.js file in your application with the keycloak.js file from the downloaded archive.
|
||||
|
||||
|
||||
[[_patching_nodejs_adapter]]
|
||||
==== Patching the Node.js adapter
|
||||
|
||||
There are no patching mechanism available for the Node.js adapter and this is distributed as a complete new download.
|
||||
|
||||
.Procedure
|
||||
To upgrade a Node.js adapter that has been copied to your web application, complete the following steps:
|
||||
|
||||
. Download the new archive.
|
||||
. Remove the existing Node.js adapter directory
|
||||
. Unzip the updated file into its place
|
||||
. Change the dependency for keycloak-connect in the package.json of your application
|
||||
|
|
@ -1,42 +0,0 @@
|
|||
[[_patching_local_maven]]
|
||||
= Patching a local Maven installation
|
||||
|
||||
If you have installed the RH-SSO Client adapters Maven Repository using a ZIP file downloaded from the link:https://access.redhat.com/[Red Hat Customer Portal], it may also need to be patched.
|
||||
|
||||
The RH-SSO Client adapters Maven Repository is available online or as a downloaded ZIP file. If you use the publicly hosted online Maven repository, updates are automatically applied, and no action is required to update it. However, if you installed the Maven repository locally using the ZIP file, you are responsible for applying updates to the repository.
|
||||
|
||||
Whenever a cumulative patch is released for RH-SSO, a corresponding patch is provided for the RH-SSO Client adapters Maven Repository. This patch is available in the form of an incremental ZIP file that is unzipped into the existing local repository. It does not overwrite or remove any existing files, so there is no rollback requirement.
|
||||
|
||||
Use the following procedure to apply updates to your locally installed RH-SSO Client adapters Maven Repository.
|
||||
|
||||
== Updating a locally installed RH-SSO client adapters maven repository
|
||||
|
||||
.Prerequisites
|
||||
|
||||
* Valid access and subscription to the Red Hat Customer Portal.
|
||||
|
||||
* The RH-SSO Client adapters Maven Repository, previously downloaded and installed locally.
|
||||
|
||||
.Procedure
|
||||
|
||||
. Open a browser and log into the link:https://access.redhat.com/[Red Hat Customer Portal].
|
||||
|
||||
. Select *Downloads* from the menu at the top of the page.
|
||||
|
||||
. Select `Red Hat Single Sign-On` from the list.
|
||||
|
||||
. Select the correct version of Red Hat Single Sign-On from the Version drop-down menu, then select the *Patches* tab.
|
||||
|
||||
. Find `Red Hat Single Sign-On 7.x.y Client adapters Incremental Maven Repository` from the list, where `x.y` match the cumulative patch number you want to update to. Select *Download*.
|
||||
|
||||
. Locate the path to your RH-SSO Client adapters Maven Repository. This is referred to in the commands below as `RH-SSO_MAVEN_REPOSITORY_PATH`. Unzip the downloaded Maven patch file directly into this directory, like this:
|
||||
|
||||
.. For Red Hat Enterprise Linux, open a terminal and run the following command, replacing the values for the cumulative patch number and your Maven repository path:
|
||||
+
|
||||
```
|
||||
$ unzip -o rh-sso-7.x.y-incremental-maven-repository.zip -d RH-SSO_MAVEN_REPOSITORY_PATH
|
||||
```
|
||||
+
|
||||
|
||||
.. For Microsoft Windows, use the Windows extraction utility to extract the ZIP file into the root of the `RH-SSO_MAVEN_REPOSITORY_PATH` directory.
|
||||
|
||||
|
|
@ -1,30 +0,0 @@
|
|||
[[_upgrading]]
|
||||
|
||||
== Upgrading the {project_name} server
|
||||
|
||||
The upgrade or migration process for the {project_name} server depends on the previous version of the software.
|
||||
|
||||
* If you are upgrading to a new minor release, for example from 7.5.x to 7.6, follow the steps in xref:_upgrading_minor[Minor Upgrades].
|
||||
|
||||
* If you are migrating from Keycloak {keycloak_upgrade_version}, follow the steps in xref:_upgrading_minor[Minor Upgrades].
|
||||
|
||||
* If you are upgrading to a new micro release, for example from 7.5.2 to 7.5.3, follow the steps in xref:_upgrading_micro[Micro Upgrades].
|
||||
|
||||
[[_upgrading_minor]]
|
||||
=== Performing a minor upgrade
|
||||
|
||||
include::../prep_migration.adoc[leveloffset=2]
|
||||
|
||||
include::../install_new_version.adoc[leveloffset=2]
|
||||
|
||||
include::../migrate_db.adoc[leveloffset=2]
|
||||
|
||||
include::../migrate_themes.adoc[leveloffset=2]
|
||||
|
||||
[[_upgrading_micro]]
|
||||
=== Performing a micro upgrade
|
||||
|
||||
include::patching-zip-installation.adoc[leveloffset=3]
|
||||
include::patching-rpm-installation.adoc[leveloffset=3]include::patching_maven_repo.adoc[leveloffset=3]
|
||||
|
||||
include::../upgrade_adapters.adoc[leveloffset=1]
|
||||
Loading…
Reference in a new issue