This provides the rest and toolkit command on how to migrate an application from one environment to another without know the client_secret in the plaintext format.

1. IBM API CONNECT
HOW TO MIGRATE AN EXISTING APPLICATION,AND
PRESERVE THE THE APPLICATION CREDENTIALS
@SPOON

2. WHY
• When generating an application with IBM APIConnect, IBM APIc will provide a client_id and client_secret
• client_secret is provided in the clear to the application developer
• Subsequent time, the client_secret will be in hashed value (there is no api to retrieve the client_secret in the clear)
Challenge:
What if you, as provider organization, need to migrate the application from one env to another, without causing an interruption to
the application.
Problem: you do not have the client_secret in the plaintext, the only value available is the hashed value of the client_secret.
Without the client_secret in the plain text, how to recreate the application with only the hashed value (and no, we did not find a
weakness in the hashing algorithm)

3. STAGING
• 1 provider org, steveorg
• 3 catalogs
• sandbox
• test
• consumerOrg: katiepoon
• moveToCatalog
• consumerOrg: movedToConsumerOrg
• 2 applications in `test` -> `katiepoon`
• app1 & app2
• Extract client_id, hashed_client_secret from app2 in catalog `test`->`katiepoon`, and mirror the app2 to catalog `movedToCatalog`->`MovedToConsumerOrg`
• I used the access_token (extracted from the UI browser)
• I am using pOrg owner’s access_token
• Same can be done with toolkit (the toolkit command included)

4. PRE-REQUISITE
• The target catalog must have setting "hash_client_secret": true
• If not, you will get this error message
• {"status":400,"message":["The client_secret_hashed property cannot be changed because the
hash_client_secret is set to 'false' in the catalog settings."]}
• rest: '/catalogs/{org}/{catalog}/settings’:
• toolkit: catalog-settings:update

5. RETRIEVE THE APPLICATION
rest: '/catalogs/{org}/{catalog}/apps’:
toolkit: apps:list --scope catalog
app_credential_urls contains
client_id & hash(client_secret)

6. EXTRACT THE CLIENT_ID * HASH(CLIENT_SECRET)
This returns all the credentials, instead of one at a time

7. APPLICATION CURRENTLY IN `STEVEORG/TEST/KATIE-POON`
I am going to move one of the app over to `steveorg/movedtocatalog/movedtoconsumerorg, which has 0 application

8. APPLICATION TO BE MOVED IS ‘APP2’
client_id : 784a9a9d319c5a53704f21bdb1ada8e5
client_secret: 15d36fd9ff05a189b4cb8f54d122e113

9. USE API TOVERIFY THE CLIENT_SECRET IS CORRECT
• rest: '/apps/{org}/{catalog}/{consumer-org}/{app}/credentials/{credential}/verify-client-secret’
• toolkit: credentials:verify-client-secret

10. CREATE AN APP IN MOVEDTOCATALOG->MOVEDTOCONSUMERORG
Note that the initial client_id and client_secret is `toberemoved`
Keep track of the `app_credential_urls, as we need this for next step

11. CREATE THE PROPER CLIENT_ID & CLIENT_SECRET FOR APP2 FROM
SOURCE APP
The quickest way is to copy the `app_credential_urls from previous slides, and remove the last id, 36bb8ssb…
The payload, I used client_secret_hashed, not client_secret

12. CHECK THE APPLICATION AGAIN, IT WILL HAVE 2 CREDENTIALS NOW

13. TEST TO MAKE SURE THE NEW (AFTER MOVED)
WORKS, USINGVERIFY-CLIENT-SECRET

14. DELETE THE `INITIAL` TOBEREMOVED CLIENT_ID & CLIENT_SECRET

15. APPLICATION,APP2 FROM TEST IS MIRRORED OVER