Tenant Backup / Restore and Templating

Tenant Backup / Restore and Templating

From version 5.6, Identify Configurator has support for exporting data from Identify database to files as well as importing data to another instance. The tool supports exporting data from version 5.1.1.4514 but you can only import data to version 5.6++.

Exporting data

Open Identify Configurator 5.6 and click Next until you reach the Select Action screen.
Choose "Export data of an instance" and select the instance from which you want to export data.

select_tenant_export_data2

Click Next to open the Export data wizard.

select_tenant_export_data3

Click on the Browse button to select a folder where exported data will be stored.

Notice: We recommend that you create separate folder for every exporting tenant. In other words, you should avoid exporting multiple tenants into the same folder

select_resources_export_data

select_folder_store_data

Select what types of resources you want to export. Use the "Select all" checkbox option to select all resources quickly.

select_resources_export_data

Note:

  • We recommend that you choose "Select all" to export all data at once to avoid data conflicts when importing.
  • The Authentication context method classes resource type is not available if the tenant’s version 5.1.1, 5.2, or 5.3.

Click Next to start exporting

start_exporting_process

Wait until Identify Configurator finishes exporting data. Click Finish to close the window.

finish_exporting_process

Verify the exported data folder:

verify_exported_folder

Note:

  • User passwords are not exported yet in version 5.6. We will support it in version 5.7.

user_exported_empty_password

  • Depending of the version of the source Identify instance, some settings may be missing from the exported data. You can try to export System Setup from both the source and target instances and update the null values to valid data. We cannot handle this part automatically for data exported from all the previous versions.

manual_edit_exported_system_setup

Importing data to a tenant

If you are importing data to another server, remember to install Identify 5.6 or later on that server first.

Importing rules

The Configurator uses the following processing rules when importing.

Importing System Setup

Importing System Setup will overwrite all settings of the destination instance but skip the following tenant-specific settings :

  • EntityIdentifier
  • BaseUrl
  • Tenant ID
  • Other url settings such as malformed request urls:
    • Malformed request page
    • NemID plugin's malformed request error page
    • SAML 2.0 plugin's malformed request error page
    • WS-Federation plugin's malformed request error page
    • UserNamePassword plugin's malformed request error page
    • One Time Password plugin's malformed request error page
    • OAuth Provider plugin's malformed request error page
    • Device-based plugin's malformed request error page
    • Ldap plugin's malformed request error page
    • GenericProvider plugin's malformed request error page
    • Yubico plugin's malformed request error page
  • Signing certificate

You don't need to modify any data before importing System Setup.

Importing Users

The default Admin user, which is specified by "IdentityBearingClaim" and "AdminUserClaimValue" in configuration file is not overwritten but all other users are. We provide a configuration file where you can specify the claim type "IdentityBearingClaim" that the Configurator will use as user’s identity bearing claim. If missing, the default value will be the Name claim.

Importing Shared Configurations

Importing Shared Configurations will overwrite all existing data such as password rules, email and SMS templates, email servers, SMS gateways, hosted forms etc.

Importing Connections, Claim Definitions, Organizations etc.

The Configurator will overwrite all existing data except:

  • The default connections for Identify Admin, Safewhere Admin, and Username & Password, their names are:
    • Username & Password
    • Identify runtime connection
    • Identify OAuth2 Token for REST APIs
  • However, the newly imported connections have their connection dependency update to the connections:
    • Username & Password
    • Identify runtime connection
    • Identify OAuth2 Token for REST APIs

The case for choosing overwriting is that even if a claim definition exists, the source claim definition may have some settings customized by users, for example
to set a claim as "not issued" or "sensitive". Those changes are updated to the destination tenant.

  • Claim definitions
    • If the claim definition is set "Restrict Elevation" in source tenant
      (exported tenant). When importing the user who has that claim may
      failed with error "You do not have enough permission to update values of
      restricted claim..." in log.
    • Solution:
      • Uncheck "Restrict Elevation" of all claims
      • Executing export and re-check the "Restrict Elevation" setting of all claims in the source tenant.
      • Executing import and check "Restrict Elevation" in destination tenant.

Note:

  1. Because Identify before version 5.4 doesn't have REST API support for authentication context class method, if you want to import data from such an old version to the latest version and your tenant is using authentication context class method, you will need to prepare data for the JSON file AuthenticationContextMethodClasses_.json before starting the import process. Here is a sample:

import_authentication_context_method_class

  1. Similarly to System Setup, some connection settings aren't available in the old versions. You need to update them manually before importing to the latest version:

    1. Protocol connection:

      • appliedHomeRealmDiscoveryRules
      • InterceptorService
      • AuthenticationListViewName
      • IsPresentLoginSelector
      • RunCustomHomeRealmDiscoveryRulesBeforeStaticRules
    2. Authentication connection:

      • CustomAuthenticationView
      • DomainBasedHomeRealmDiscoveryFilter
      • interceptorService

Importing Organizations

We skip updating the Root organization.

Configuration file

Users
  • "NormalUserIdentityBearingClaimType": This claim type specifies the identity bearing claim type that the Configurator uses to check if a user exists in the destination tenant. If a user exists in the destination tenant, the Configurator will update the user.

  • "AdminUserIdentityBearingClaimType" and "AdminUserIdentityBearingClaimValue": This claim type and claim value are used to find out that user is the Admin user of the destination tenant.

The main flow for importing user data:

  1. Use "AdminUserIdentityBearingClaim" and "AdminUserIdentityBearingClaimValue" to GET the admin user's ID. If no user is returned, stop importing with error message: Couldn't determine the Admin user by using {claim type, claim value}. Importing users stopped to avoid accidentally overwriting the Admin user.
  2. Get the list of all claim definitions from the destination tenant.
  3. For each user in the exported user list:
    a. Using the claim definitions from step 2, check if a user object has any claim whose type is not defined in the destination tenant

    b. If the user has the "NormalUserIdentityBearingClaimType" claim, find the user from the destination tenant by "NormalUserIdentityBearingClaimTthe ype" and user's claim value.

    c. If the user does not have the "IdentityBearingClaim" claim, send HTTP POST to create a new user.

Connections

The IgnoreImportConnections setting specifies a list of connections that the Configurator will skip when it imports connections.

Debugging unsuccessful imports in log files

Configurator log

After the Identify Configurator finishes importing, you can the result of the import process by viewing the log file at C:\IdentifyLogs\Configurator_yyyy_mm_dd.txt.

icc_logs

FaultyImportData log

The Identify Configurator also logs resources that it has failed to import in the C:\IdentifyLogs\FaultyImportData_[TenantID] folder. Each resource type has its own log file named [IdentifyResource]_FaultyResult.json such as Users_FaultyResult.json, Groups_FaultyResult.json, ProtocolConnections_FaultyResult.json, AuthenticationConnections_FaultyResult.json and so on. Inside the log files, you can find the action that has been done for each resource:

  • SKIP: The configurator skipped importing the resource.
  • CREATE: The configurator failed to create the resource on the destination tenant.
  • UPDATE: The configurator failed to update the resource on the destination tenant.