Upgrade
Supported Upgrade Paths
The following table lists supported upgrade paths to IG 7.1:
Version | Upgrade supported? |
---|---|
IG 6.x |
✔ |
IG 7.x |
✔ |
For more information, see Checking your product versions are supported in the ForgeRock Knowledge Base.
For unsupported, legacy deployments, ForgeRock can assist you in the upgrade process.
Planning the Upgrade
Major, minor, maintenance, and patch product release levels are defined in ForgeRock Product Release Levels. How much you need to do to upgrade IG software depends on the magnitude of the differences between the version you currently use and the new version.
Minor, maintenance, and patch releases have a limited effect on current functionality but contain necessary bug and security fixes. Keep up-to-date with maintenance and patch releases because the fixes are important, and the risk of affecting service is minimal.
Do these planning tasks before you start an upgrade:
Planning task | Description |
---|---|
Find out what changed |
Read the Release Notes for all releases between the version you currently use and the new version. |
Understand the impact |
Decide whether you need to change the configuration of your deployment for this release, and evaluate the work involved. Make sure you meet all of the requirements for the new version. In particular, make sure that you have a recent, supported Java version. |
Plan for server downtime |
At least one of your IG servers will be down during upgrade. Plan to route client applications to another server until the upgrade process is complete, and you have validated the result. Make sure client application owners are aware of the change, and let them know what to expect. If you have a single IG server, make sure the downtime happens in a low-usage window, and make sure you let client application owners plan accordingly. |
Back up |
The IG configuration is a set of files, including Also back up any tools scripts that you have edited for your deployment, and any trust stores used to connect securely. |
Plan for rollback |
Sometimes even a well-planned upgrade fails to go smoothly. In such cases, you need a plan to roll back smoothly to the pre-upgrade version. For IG servers, roll back by restoring a backed-up configuration. |
Prepare a test environment |
Before applying the upgrade in your production environment, always try to upgrade IG in a test environment. This will help you gauge the amount of work required, without affecting your production environment, and will help smooth out unforeseen problems. The test environment should resemble your production environment as closely as possible. |
Upgrade the IG Configuration
Use the Release Notes for all releases between the version you currently use and the new version, and upgrade your configuration as follows:
-
Review all Incompatible Changes, and adjust your configuration as necessary.
-
Switch to the replacement settings in Deprecation. Although deprecated objects continue to work, they add to the notifications in the logs, and are eventually removed.
-
Check the lists of Fixes, Limitations, and Known Issues, to see if they impact your deployment.
-
Recompile your Java extensions. The method signature or imports for supported and evolving APIs can change in each version.
-
Read the Documentation Updates for new examples and information that can help with your configuration.
Upgrade IG Instances
For information about the versions that are supported for upgrade, see Supported Upgrade Paths.
Upgrade a Single IG Instance
-
Read and act on Plan the Upgrade and Upgrade the IG Configuration.
-
Back up the IG configuration, and store it in version control so that you can roll back if something goes wrong.
-
Stop IG.
-
Make the new configuration available on the file system, and specify the
IG_INSTANCE_DIR
env variable orig.instance.dir
system property to point to them. -
Restart IG.
-
In a test environment that simulates your production environment, validate that the upgraded service performs as expected with the new configuration. Check the logs for new or unexpected notifications or errors.
-
Allow client application traffic to flow to the upgraded site.
Migrate From Web Container Mode to Standalone Mode
IG is delivered as a standalone Java executable in a .zip file, as well as in a .war file. Consider these points to migrate from IG in web container mode to IG in standalone mode.
Session Replication Between IG Instances
High-availability of sessions is not supported in standalone mode.
Streaming Asynchronous Responses and Events
In ClientHandler and
ReverseProxyHandler,
use only the default mode of asyncBehavior:non_streaming
; responses are
processed when the entity content is entirely available.
If the property is set to streaming
, the setting is
ignored.
Connection Reuse When Client Certificates Are Used for Authentication
In ClientHandler and
ReverseProxyHandler,
use only the default mode of
stateTrackingEnabled:true
; when a client certificate is used for
authentication, connections cannot be reused.
If the property is set to false
, the setting is ignored.
Tomcat Configuration
Feature | Standalone | Tomcat |
---|---|---|
Port number |
Configure the |
Configure in the
|
HTTPS server-side configuration |
Create a keystore, set up secrets, and configure secrets stores, ports, and ServerTlsOptions in admin.json. For information, see Configure IG For HTTPS (Server-Side) in Standalone Mode. |
Create a keystore, and set up the SSL port in the For information, see Configure IG for HTTPS (Server-Side) in Tomcat. |
Session cookie name |
Configure the |
Configure |
Access logs |
Configure in the Audit framework. For information, see Auditing Your Deployment and Audit Framework. |
Configure with |
JDBC datasource |
Configure with the JdbcDataSource object. For information, see JdbcDataSource. For an example, see Log In With Credentials From a Database. |
Configure in the |
Environment variables |
Configure in |
Configure in |
Jar files |
Add to |
Add to to web container classpath; for example
|