This article describes how to export CTS-based tokens from OpenDJ 3.x, DS 5.x or DS 6 (that have been created with OpenAM 13.x, AM 5.x or 6.0.x) and import them into DS 6.5.x for use in AM 6.5.x.
The idea behind this article is to allow for a complete migration scenario to DS 6.5.x and AM 6.5.x without disruption as far as OAuth 2.0 clients are concerned. This article is split as follows:
OAuth 2.0 token management
A grant-set storage scheme was introduced in AM 6.5, which the release notes describe as "Improved CTS Storage Scheme for OAuth 2.0 tokens"; you can read more about this here: Release Notes › New Features: What's New in AM 6.5. This storage scheme stores the state of multiple authorizations for a given OAuth2 client and resource owner pair in a single OAUTH2_GRANT_SET object. Additionally, it groups Access and Refresh tokens into a single JSON object within the LDAP object (in the coreTokenMultiString03 entry). This approach reduces duplication and the number of calls to the CTS, which in turn improves AM performance. The previous storage scheme by comparison was considered a 1:1 storage scheme.
You can see what example tokens looks like for the new OAUTH2_GRANT_SET token type and the previous OAUTH token type in How do I know what OAuth2 and session token types are stored in the CTS in AM/OpenAM (All versions)? Additionally, there are fewer indexed attributes with the grant-set storage scheme, which optimizes AM to CTS request response times. The OAUTH2_GRANT_SET has four indexed attributes compared to eight indexed attributes with OAUTH.
CTS-based tokens created in OpenAM 13.x, 5.x, and 6.0.x do not have grant-set storage. Unfortunately, the CTS cannot handle both 1:1 and grant-set storage schemes concurrently in a migration scenario. This is a known issue: OPENAM-15627 (Switching CTS Storage Scheme to "Grant-set" fails with refresh-tokens created with "One-To-One" ).
As indicated in the following table, the storage scheme has to be set to 1:1 if legacy Access and/or Refresh tokens are imported from an old AM/OpenAM version into AM 6.5.x:
|Tokens||Client-Based Grant Token Upgrade Compatibility Mode*||CTS Storage Scheme*||Legacy Refresh Tokens?||Performance|
|OAUTH2_STATELESS_GRANT tokens||ON||Grant-Set||Not Allowed due to known issue: OPENAM-15627||Improved, but still sub-optimum|
* The global settings in this table can be found by navigating to Configure > Global Services > OAuth2 Provider > Global Attributes in the console.
Migrating OAuth 2.0 tokens
- Deploy the new AM environment. See Release Notes, Deployment Planning Guide, Installation Guide and Upgrade Guide for further information.
- Create a full backup of DS in both the new and old environments. See Installation Guide › Exporting and Importing Data in DS by using LDIF for further information.
- Create a backup of the configuration store and CTS store in both the new and old environments. See Administration Guide › Backing Up and Restoring Data for further information.
- Export the data from the old CTS store and import it into the new one.
Once you have completed these steps, you can do some testing such as introspect the OAuth2 Access and Refresh tokens on the new AM version to check the validity of the Refresh tokens. See OAuth 2.0 Guide › /oauth2/introspect for further information.
Export and import CTS data
- Export CTS tokens from the old AM/OpenAM version using the export-ldif command. You can export all tokens or a subset of tokens as required. The following examples demonstrate exporting all tokens and different subsets of tokens with the server online; you must include the --offline option if the server is stopped in AM 5 and later / DS 5 and later:
- Export all tokens: $ ./export-ldif --hostname oldAM.example.com --port 4444 --bindDN "cn=Directory Manager" --bindPassword password --ldifFile /path/to/tokens.ldif --includeBranch ou=famrecords,ou=openam-session,ou=tokens,dc=openam,dc=forgerock,dc=org --backendID amCts --trustAll
- Export only Refresh tokens: $ ./export-ldif --hostname oldAM.example.com --port 4444 --bindDN "cn=Directory Manager" --bindPassword password --ldifFile /path/to/tokens.ldif --includeBranch ou=famrecords,ou=openam-session,ou=tokens,dc=openam,dc=forgerock,dc=org --includeFilter "(coreTokenString10=refresh_token)" --backendID amCts --trustAll
- Export Access and Refresh tokens: $ ./export-ldif --hostname oldAM.example.com --port 4444 --bindDN "cn=Directory Manager" --bindPassword password --ldifFile /path/to/tokens.ldif --includeBranch ou=famrecords,ou=openam-session,ou=tokens,dc=openam,dc=forgerock,dc=org --includeFilter "(|(coreTokenString10=refresh_token)(coreTokenString10=access_token))" --backendID amCts --trustAll
- Remove any lines from the export file that do not relate to tokens. This may happen if you've exported everything. If you've used the --includeFilter to specify tokens, you can skip this step.
- Back up the new CTS using the export-ldif command: $ ./export-ldif --hostname newAM.example.com --port 4444 --bindDN "cn=Directory Manager" --bindPassword password --ldifFile /path/to/ctsbackup.ldif --backendID amCts --trustAll
- Make a backup of the backup you just created: $ cp /path/to/ctsbackup.ldif /path/to/ctsbackup.ldif.backup
- Concatenate your backup and the export from step 1 to create a new ldif file: $ cat /path/to/ctsbackup.ldif /path/to/tokens.ldif > /path/to/ctsnew.ldif
- Place the resulting file (for example ctsnew.ldif) in the /path/to/ds directory on the new CTS instance.
Do not proceed unless you are certain that the previous steps have completed successfully. If the following import-ldif command fails (for example, due to filename errors or if a previous step was not completed), there is a high chance that you will end up with a corrupted CTS that cannot be recovered.
- Import the file into the new AM 6.5.x instance using the import-ldif command, for example: $ ./import-ldif --hostname newAM.example.com --port 4444 --bindDN "cn=Directory Manager" --bindPassword password --ldifFile /path/to/ctsnew.ldif --backendID amCts --trustAll