Upgrading OpenAM Servers

This chapter covers upgrade from OpenAM core server 11.0.0 or later to the current version. For other OpenAM components, see "Upgrading OpenAM Components".

OpenAM server upgrade relies on the Upgrade Wizard to make the necessary changes to the configuration store. You must then restart OpenAM or the container in which it runs. Even a version number change requires that you run the Upgrade Wizard, so needing to run the Upgrade Wizard says nothing about the significance of the changes that have been made to OpenAM. You must run the Upgrade Wizard even for maintenance releases.

Make sure you try upgrading OpenAM in a test environment before applying the upgrade in your production environment.

If you are upgrading from an unsupported version of OpenAM to a later version, you must first upgrade to a supported version. In some cases, you may need to upgrade again depending on the upgrade path.
To Upgrade From a Supported OpenAM Version

Follow these steps to upgrade a site of OpenAM servers.

During the upgrade process, you must take the OpenAM servers in the site out of production, instead redirecting client application traffic elsewhere. This is required because upgrade involves making changes to OpenAM’s configuration model. If the upgrade fails, you must be able to roll back before the configuration changes impact other sites.

Do not perform an upgrade by deploying the new version and then importing an existing configuration by running the ssoadm import-svc-config command. Importing an outdated configuration can result in a corrupted installation.

  1. Prepare your customized OpenAM server .war file.

  2. Back up your deployment.

  3. Route client application traffic to another site during the upgrade.

  4. For servers in the site, stop OpenAM, or if necessary stop the container where OpenAM runs.

  5. For servers in the site, deploy your customized server .war file.

    When you deploy the new .war file, you might have to delete working files left by the old installation. For example, if you deploy on Apache Tomcat, replacing /path/to/tomcat/webapps/openam.war, then also recursively delete the /path/to/tomcat/webapps/openam/ and /path/to/tomcat/work/Catalina/localhost/openam/ directories before restarting the server.

  6. For servers in the site, restart OpenAM or the container where it runs.

  7. To upgrade the data in the configuration store, perform one of the following actions in one of the servers in the site:

    • Navigate to the OpenAM URL, for example https://openam.example.com:443/openam, and follow the instructions in the Upgrade Wizard for an interactive upgrade.

    • Use the openam-upgrade-tool-15.2.1.jar tool for an unattended upgrade:

      1. Install the openam-upgrade-tool-15.2.1.jar tool as described in "To Set Up Configuration Tools" in the Installation Guide. A sampleupgrade file will be expanded in the directory where you install the tool.

      2. Create a configuration file for the openam-upgrade-tool-15.2.1.jar. You can use the sampleupgrade file as a template to create a configuration file, for example upgrade.properties.

        An upgrade configuration file may resemble the following:

        $ grep -v "^#" upgrade.properties
    SERVER_URL=http://openam.example.com:8080
     DEPLOYMENT_URI=/openam
     ACCEPT_LICENSES=true

      3. Upgrade OpenAM by using the tool with the properties file following this example:

        $ java -jar openam-upgrade-tool-15.2.1.jar --file upgrade.properties

Writing Backup; Done.
Upgrading Services
New service iPlanetAMAuthPersistentCookieService; Done.
New service iPlanetAMAuthOpenIdConnectService; Done.
New service OAuth2Provider; Done.
New service iPlanetAMAuthDevicePrintModuleService; Done.
New service crestPolicyService; Done.
New service RestSecurity; Done.
New service MailServer; Done.
New service dashboardService; Done.
New service iPlanetAMAuthOATHService; Done.
Add Organization schema to sunFAMSAML2Configuration; Done.
Upgrade sunAMAuthHOTPService; Done.
Upgrade sunAMAuthADService; Done.
Upgrade sunAMAuthOAuthService; Done.
Upgrade iPlanetAMAuthCertService; Done.
Upgrade sunIdentityRepositoryService; Done.
Upgrade iPlanetAMPasswordResetService; Done.
Upgrade iPlanetAMSessionService; Done.
Upgrade iPlanetAMAuthService; Done.
Upgrade iPlanetAMAuthLDAPService; Done.
Upgrade sunAMAuthDataStoreService; Done.
Upgrade AgentService; Done.
New sub schema sunIdentityRepositoryService; Done.
New sub schema AgentService; Done.
Delete service sunFAMLibertyInteractionService; Done.
Delete service sunFAMLibertySecurityService; Done.
Creating entitlement application type crestPolicyService; Done.
Creating entitlement application crestPolicyService; Done.
Re-enabling Generic LDAPv3 Data Store; Done.
Upgrading data store embedded; Done.
Updating Platform Properties; Done.
Writing Upgrade Log; Done.

Upgrade Complete.

        For additional information about the command-line tool, see the reference documentation for upgrade.jar(1) in the Reference.

      4. Restart OpenAM or the container where it runs.

  8. (Optional) If you installed OpenAM using an external directory server as the configuration store, add an access control instruction (ACI) to the external directory to give the OpenAM administrative user server-side sorting privileges.

    The ACI should be similar to the following:

    aci: (targetcontrol="1.2.840.113556.1.4.473")(version 3.0;acl "Allow
 server-side sorting"; allow (read)(userdn = "ldap:///
 uid=openam,ou=admins,dc=example,dc=com");)

    See "Preparing an External Configuration Data Store" in the Installation Guide for more information about using an external directory server as the OpenAM configuration store.

  9. (Optional) If you want to configure the upgraded system for the Core Token Service (CTS), read "Configuring the Core Token Service" in the Installation Guide.

  10. Referral policies are not supported in OpenAM 15.2.1. If your OpenAM deployment has referral policies, the following warning message will appear when you upgrade your OpenAM server to OpenAM 15.2.1:

    Referrals found that require removing

    OpenAM will take the following actions during the upgrade:

    • Removing all referral policies from your OpenAM configuration.

    • Copying resource types and policy sets associated with removed referral policies to the realms targeted by the referral policies.

    For example, suppose you had an OpenAM 12 deployment with a referral policy in realm A, and that referral policy referred to policies in realm B. During an upgrade, OpenAM would delete the referral policy in realm A and copy all the resource types and policy sets associated with the deleted referral policy from realm A to realm B.

    After upgrading to OpenAM 15.2.1, you are responsible for reconfiguring OpenAM so that policy evaluation that previously depended upon referrals continues to function correctly. You might need to take one or both of the following actions:

    • Reconfiguring your policy agent with the realm and policy set [1] that contain policies to be evaluated when that agent requests a policy decision from OpenAM. Previously, you might have configured the agent to use a realm that contained a referral policy. Because referral policies are not supported in OpenAM 15.2.1, this is no longer possible.

    For more information about configuring an agent with a realm and policy set, see "Working With Realms and Policy Agents" in the Administration Guide.

    • Copying or moving a policy or a group of policies. OpenAM 15.2.1 has new REST API endpoints that let you copy and move policies. This functionality might be helpful when migrating away from policy deployments that use referral policies. For more information about the REST endpoints that let you copy and move policies, see "Copying and Moving Policies" in the Developer’s Guide.

  11. Validate that the service is performing as expected.

  12. Allow client application traffic to flow to the upgraded site.

To Complete Upgrade from OpenAM 11.0.x

After upgrade from OpenAM 11.0.x, all OAuth 2.0 client configurations inherit the default response types:

  • code

  • token

  • id_token

  • code token

  • token id_token

  • code id_token

  • code token id_token

  1. For each OAuth 2.0 client configuration, edit the list of response types to remove any that are not supported or not required.

  2. For each OAuth 2.0 client configuration, update the client password.

    As part of a fix for OpenID Connect ID Token signing, the password storage format for OAuth 2.0 clients has changed. OpenAM now stores client passwords using reversible encryption. OpenAM 11.0 stores client passwords using a one-way hash algorithm, and therefore the passwords cannot be recovered.

    You can update the client password by using either OpenAM console or the ssoadm update-agent command with the --attributevalues option to update the value of the userpassword attribute.

To Complete Upgrade from OpenAM 13.0.x

If you configured one or more JDBC audit event handlers in OpenAM 13.0.x, make the following changes to the audit tables' schema:

  1. Run the following command on Oracle databases that support OpenAM audit event handlers:

    ALTER TABLE am_auditaccess ADD (response_detail CLOB NULL);

    This command adds the response_detail column to the am_auditaccess table.

  2. Run the following commands on MySQL databases that support OpenAM audit event handlers:

    ALTER TABLE audit.am_auditconfig CHANGE COLUMN configobjectid objectid VARCHAR(255);
ALTER TABLE audit.am_auditaccess ADD COLUMN response_detail TEXT NULL;

    The commands change the name of the configobjectid column in the am_auditconfig table to objectid and add the response_detail column to the am_auditaccess table.

  3. If you use databases other than Oracle or MySQL to support OpenAM audit event handlers, review their schema.

    If the am_auditconfig table has a column named configobjectid, change that column’s name to objectid.

    If the am_auditaccess table does not have a column named response_detail, add that column to the table’s schema.

1. The agent configuration UI refers to a policy set as an application.