Migrating non-production to production environment

Migrating RPM deployment

1. Install OpenIAM on the production server using the same rpm file that you used on the non-production server. This will take care of installing same versions of infrastructure stack and OpenIAM jar/war files.

2. Migrate DB (optional). You should decide if you want to migrate DB or start from scratch. If you decide to migrate DB you should clear test data (users,roles,groups etc.) before start, otherwise it will clog up production. that was created during UAT (User Acceptance Testing). Based on database type use migration tool. mysqldump for mariadb; pg_dump for postgresql etc.

   1. Export data from openiam database into file (ex for mariadb: mysqldump -uroot -pRootPassword openiam --ignore-table=openiam.DATA_WORKFLOW_RPT_VIEW --ignore-table=openiam.WORKFLOW_STATUS_RPT_VIEW > /tmp/openiam.sql)
   2. Import data into prod database (ex for mariadb: mysql -uroot -pRootPassword openiam < /tmp/openiam.sql).
   3. During DB migration, we do not migrate sensitive data. To clear sensitive data in DB by following SQL

       UPDATE LOGIN SET PASSWORD='passwd00';
       DELETE FROM USER_KEY;
       UPDATE MANAGED_SYS SET PSWD = NULL;
       UPDATE SYNCH_CONFIG SET SRC_PASSWORD = NULL;
       DELETE FROM PWD_HISTORY;
       DELETE FROM USER_IDENTITY_ANS;
       DELETE FROM OAUTH_TOKEN;
       DELETE FROM USER_TOKEN;
       DELETE FROM AUTH_STATE_AUTH_PARAM_XREF;
       DELETE FROM USER_AUTH_PARAM;

   4. Restart httpd service.
   5. You will need to re-input password in managed systems, SMTP configuration, sync configurations (RDBMS adapters only). User's password will be reset to default passwd00.

3. Migrate groovy scripts. Zip directory /usr/local/openiam/conf/iamscripts and copy over to prod server and unzip with replacement into the same directory in prod server. If scripts contain hardcoded object IDs good practice would be to avoid it, at least for not out-of-the-box IDs. In case you must use hardcoded IDs: start OpenIAM, create needed objects, pick up new IDs and replace in groovy scripts accordingly. If you did DB migration, then DB objects will keep same IDs. You can continue using those IDs in groovies.

4. Migrate activiti xml file if any changes were done in workflow files. Zip directory /usr/local/openiam/conf/activiti and copy over to prod server and unzip with replacement into the same directory in prod server.

5. Start OpenIAM on prod server. Run command in ssh terminal to rebuild graph. curl http://127.0.0.1:9080/openiam-esb/authmanager/rebuildGraph

6. Login, and create new content provider.

7. Option with DB migration

   1. delete content provider for non-prod URL.
   2. Validate managed systems connection parameters, very possible that you should change non prod target applications URL to prod. Check service accounts to be aligned with prod.
   3. Validate SMTP configuration to be aligned with prod configuration.
   4. Validate authentication providers, if any certificates from target systems were issued for non-prod server, you should initiate re-issue and upload valid certificates.

8. Option without DB migration

   1. migrate all UI configurations from non-prod: managed system configurations, synchronizations, batch tasks, auth providers etc.
   2. if required created access roles, create admin users and grant them proper access.