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 it 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. Make sure to use a migration tool based on database type, e.g. mysqldump for MariaDB; pg_dump for PostgresQL, etc.
3. Export data from OpenIAM database into file. For example, for MariaDB use

mysqldump -uroot -pRootPassword openiam --ignore-table=openiam.DATA_WORKFLOW_RPT_VIEW --ignore-table=openiam.WORKFLOW_STATUS_RPT_VIEW > /tmp/openiam.sql

4. Import data into a production database For example, for MariaDB use

mysql -uroot -pRootPassword openiam < /tmp/openiam.sql

5. During DB migration, we do not migrate sensitive data. To clear sensitive data in DB use 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;

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

7. 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.

8. 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.

9. Start OpenIAM on prod server. Run the following command in ssh terminal to rebuild graph.

curl http://127.0.0.1:9080/openiam-esb/authmanager/rebuildGraph

10. Login and create new content provider.

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-production target applications URL to production. 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.

Option without DB migration

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