Plan the upgrade
How much you must do to upgrade AM software depends on the magnitude of the differences between the version you currently use and the new version:
-
Maintenance releases have a limited effect on current functionality but contain necessary bug and security fixes. Keep up to date with maintenance releases, as the fixes are important and the risk of affecting service is minimal.
-
When upgrading to a new major or minor release, always plan and test the changes before carrying out the upgrade in production. Make sure you read the release notes for intervening versions with care. Identify any changes likely to affect your deployment and then plan accordingly.
Review the following best practices before you upgrade AM:
Route around servers during downtime
Upgrading servers takes at least one of your AM sites down while you update the server configurations to the new version. Plan for this site to be down. Route client applications to another site until the upgrade process is complete, and you have validated the result. Make sure client application owners are well aware of the change, and let them know what to expect.
If you only have a single AM site, make sure the downtime happens in a low-usage window, and make sure you let client application owners plan accordingly.
During an upgrade, restrict access to the AM console: The Upgrade Wizard page doesn’t require authorization; any user with access to the AM admin UI immediately after you deploy the new WAR file can therefore start the upgrade process.
Back up the deployment
Always back up your deployment before you upgrade. If something goes wrong during the upgrade process, you can then roll back to the previous version.
-
In production environments, back up your configuration as described in Back up configurations.
-
In preparation for upgrading AM servers and their configurations, also take LDIF backups of the configuration store data in the directory servers. If possible, stop servers before upgrading and take a file system backup of the deployed servers and also of their configuration directories as well. This can make it easier to roll back from a failed upgrade.
For example, if you deploy AM server in Apache Tomcat under
/openam, you might take a file system backup of the following directories for each AM server.-
/path/to/tomcat/webapps/openam/ -
~/openam/ -
~/.openamcfg/
-
-
When upgrading tools, keep copies of any scripts you’ve edited for your deployment.
-
Back up the key stores and trust stores you use to connect securely.
-
Record any custom advanced server properties configured under Configure > Server Defaults > Advanced or Deployment > Servers > Server Name > Advanced in the AM admin UI. These properties are lost during the upgrade and must be re-added after the upgrade is complete.
Review REST API versions before upgrading
Upgrading AM may update the default API version of several AM endpoints. After an upgrade, your applications may experience issues connecting to endpoints if they don’t specify API version information in REST calls.
By default, an upgraded AM instance responds to REST calls that don’t specify version information with the oldest version available for the endpoint. However, the oldest supported version may not be the one required by the application, as API versions become deprecated or unsupported.
To avoid version conflicts between application calls and REST endpoint APIs,
consider specifying the protocol and resource version required by the application
in the Accept-API-Version header when making requests to REST endpoints.
For details, refer to Specify REST API versions.
|
From version 6, AM includes a CSRF protection filter that’s enabled by default.
REST requests other than GET, HEAD, and OPTIONS made to endpoints under the For details, refer to Protect against CSRF attacks. |
You can configure AM’s default REST API behavior. For details, refer to Configure versioning behavior.
Review PingDS certificates before upgrading
Before you upgrade, review the certificates used to establish secure connections between AM and the DS stores.
If the FQDN value from the subject field of a non-wildcard certificate
doesn’t match the FQDN obtained from DNS for the DS instance,
AM can’t establish a secure connection with DS.
Additionally, if the DS instance responds to multiple FQDNs, you must also specify them in the certificate.
This step is critical for the configuration store. If AM cannot establish communication with the configuration store, it will fail to start up.
For more information about setting up DS server certificates, refer to Key management in the DS documentation.
Customize before upgrading
Prepare a .war file that contains any customizations you require.
Customizations include any changes you have made to the AM server installation, such as the following:
-
Custom plugin and extensions, for example:
-
Custom authentication modules.
-
Custom authentication nodes.
-
Post-authentication plugins.
-
Custom SAML v2.0 attribute mappers.
-
Custom OAuth 2.0 scope validators.
New functionality often changes the samples provided with AM.
Don’t copy custom plugins or extensions from a previous version of AM to the
.warfile.You must customize the samples of the version you’re upgrading to before adding them to the
.warfile. For example, download the custom scope validator sample of the version you’re upgrading to, customize it, recompile it, and then add the resulting.jarfile to the.warfile.Failure to use the new version’s samples as the base for your customizations may result in unexpected behavior.
-
-
Customized JSPs, redesigned login or service pages, additional CSS and visual content, and modified authentication module callback files.
-
Any changes to AM classes or APIs.
Recompile any custom implementations you have created with each release of AM, as the method signature or imports for supported and evolving APIs can change in each version.
-
Any changes or additional Java class libraries (such as .jar files in
WEB-INF/lib).
Plan for rollback
Sometimes even a well-planned upgrade operation fails. In such cases, you need a plan to roll back to the pre-upgrade version.
For AM servers, you can roll back by restoring from file system backup. If you use an external configuration directory service, restore the old configuration from LDIF before you restart the old servers. For details, refer to Back up configurations.
| If you upgraded using the upgrade wizard and need to roll back the upgrade, you must restore the default keystore. The upgrade wizard removes a default alias that AM versions before AM 7.4 need to start. If you don’t restore this alias, the rolled back instance of AM won’t start up. |