Last reviewed: 2019-07-08
NOTE: These instructions require CustomerID 5 to be installed over an existing CustomerID 4 installation. If you want to build a separate environment for CustomerID 5 the data from LDAP in CID 4 environment has to be separately migrated into the new environment. Consult Ubisecure if you need advice on how to achieve this.
Issue all the commands using the root user account.
NOTE: If you are upgrading from a version lower than 4.6.x then you need to do the upgrade in two steps. First upgrade to version 4.6.x and then upgrade to the newest version. Direct upgrade to the newest version is only possible from version 4.6.x.
Stopping Ubisecure CustomerID Services
Ubisecure CustomerID services can be stopped by using the following command:
Make sure no changes are made to the database during following steps.
Set Up the Derby-to-PostgreSQL Migration Tool
Extract the migration tool package
cid-database-migration-package-x.x.x-linux.tar.gz to /usr/local/ubisecure/migration-tool.
Use the Migration-Tool to Export Data from Derby DB
Environment variables used by the migration-tool:
|DERBY_HOME||The path where Derby DB is installed.|
|DERBY_CONNECTION_URL||JDBC connection URL of the Derby DB.|
|DERBY_PASSWORD||The password of Derby user.|
|MIGRATION_JAR_FILE||The jar file containing migration implementation.|
Use the following lines as an example how to setup your own environment variables from the command line. Edit values to match your own environment.
Run DerbyExportWithCopy functionality of the migration-tool to export data from the existing Derby DB:
The DerbyExportWithCopy functionality of the migration-tool will create .sql scripts into
export-results-batch subfolder that can be used to import existing data to PostgreSQL. It may take a while to perform this, depending on how much data is stored in Derby database. If the tool discovers pre-existing sql files in this folder with the same name as what it is going to write, it will interrupt its work and exit. So, if you have to fix something and re-run the command, you will have to ensure that the export-results folder is empty before you do so.
Backing up Ubisecure CustomerID
See instructions from Backup and restore - CustomerID.
Backing up Ubisecure Directory (OpenLDAP)
See instructions from Backup and restore Ubisecure Directory - SSO.
Uninstalling and Deleting the Old Installation
The Ubisecure CustomerID services and related user account must be deleted before proceeding with the update by running:
Rename old installation folder:
Unpacking the New Distribution Package
If you have an existing WildFly installation, you need to uninstall it and install the one included in the distribution package.
For instructions installing (and uninstalling) WildFly see WildFly installation on Linux - CustomerID.
Extract the deployment template
Extract the archive
Importing configuration settings from the old installation
In order to resume the service after the upgrade, it is necessary to copy some configuration settings from the previous installation. These settings are contained in the file
In the new installation the
linux.config file is located further down the similar path in the subfolder config and must first be copied to the application folder.
The values must be copied carefully as the configuration options may have changed. You should copy only those values that have the same keys on both old and new
NOTE: A large change was done between the 4.6.x and 5.0.x versions.
Running setup script
NOTE: If you have made configuration changes to any of the
linux.config parameters after previously running the
setup.cmd, ensure that these changes are included in the new
linux.config file. For example, if you have changed the REST credentials in
eidm2.properties file, make sure the same values are now present in the
Preparing a database for Ubisecure CustomerID
When preparing SQL, skip the Applying the CustomerID DDL to PostgreSQL chapter.
Create JDBC Data Source To WildFly
Modify Directory Service for Ubisecure CustomerID Internal Database
Use the migration-tool to import the data to PostgreSQL
You have to create an empty PostgreSQL database and the CustomerID database user before import.
Environment variables used by the import-tool:
|PGUSER||The username which is used to access PostgreSQL database.|
|PGPASSWORD||The password of PGUSER.|
|PGCLIENTENCODING||The character encoding to use when accessing PostgreSQL DB. Typically UTF-8.|
|PGPORT||This is the TCP port where PostgreSQL can be accessed.|
|PGHOST||The DNS host name or IP address of PostgreSQL server.|
|PG_CONNECTION_URL||JDBC connection URL of the PostgreSQL DB.|
|MIGRATION_JAR_FILE||The jar file containing migration implementation.|
Use the following lines as an example how to setup your own environment variables from the command line. Edit values to match your environment.
Create tables to the PostgreSQL DB:
Initialize the DB with internal data used by the CustomerID:
Import previously exported Derby DB data to the PostgreSQL DB:
Use the following command if you need to drop database tables before a new attempt (for example after correction of the data):
Validating the data
When the data has been imported, run DataCleanup functionality of the migration-tool to make sure that the data has been imported properly.
This functionality will write errors in a log file called
CLEANUPRESULTS.txt. If there were errors in the data import it is possible to repair them manually using an SQL client to connect to PostgreSQL. How to repair depends on the nature of the error and in this case you may have to consult Ubisecure support.
When all errors have been fixed, you should run DataCleanup functionality of the migration-tool again and check the log file if the data is consistent.
It is known issue, that Organization EntityNames will get URL encoded, which causes some special letters and non-ASCII letters to malform. This is known to cause those organizations to be unaccessible. To fix this issue, change broken organizations Entity Name and Technical Name contain characters allowed in URL. (See RFC 3986: Unreserved characters)
Creating constraints and indexes
When the data has been validated, execute the following commands to create indexes and constraints to the tables.
Restoring the Local Customizations
NOTE: Before replacing the custom folder, make sure there are no new additions in the configuration files. If there are, update your old customizations to support new configurations before replacing the files. The page CustomerID Configuration Changes In Versions lists all changes you need to do between different versions. Using that document as a guide delete all removed keys, add new ones if needed and replace all changed keys.
Restore the old custom folder with the following commands:
NOTE: Starting from Ubisecure CustomerID 5.0.x version back channel logout is no longer supported. If you have had that enabled you need to disable it before proceeding. Add the compatibility flag ( LiteNoBackChannel ) to your identity.properties files and generate new metadata. Finally upload the new metadata to Ubisecure SSO Management. See instructions from SAML SP activation - SSO.
Deploying Ubisecure CustomerID
Ubisecure CustomerID uses WildFly as a J2EE Container. This chapter describes how to deploy the
cid-ear-x.x.x.ear and cid-worker-ear- x.x.x .ear enterprise archives (EARs).
Deploy the Ubisecure CustomerID application to WildFly using the deploy-ear.sh command. When invoking the command, you must supply the path to the ear file, like in the example below:
If a reverse proxy is used in SELinux:
Ubisecure CustomerID SSO Adapter Upgrade
UPGRADE IS NOW COMPLETE! Log in with your credentials.