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 but you can only import
data to version 5.6++.

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


Click Next to open the Export data wizard.


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

Notice: System recommend is create difference folder for every exporting tenant. (User should not export multiple tenants into the same folder)



Select what type of resources you want to export. Use the “Select all”
option to select all resources quickly.



  • We recommend you to choose “Select all” to export all data at once. Besides, the configuration file is generated with its full content.

  • 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


Wait until Identify Configurator finishes exporting data. Click Finish button


Verify the exported data folder:



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


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


Import data to a tenant

If you are importing data to another server, remember to install Identify 5.6 or later 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 specify by “IdentityBearingClaim” and
“AdminUserClaimValue” in configuration file is not
overwritten but all other users are. We provide a configuration
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.


  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:


  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


  • “NormalUserIdentityBearingClaimType”: This claim type sspecifies 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” ad “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

  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.


IgnoreImportConnections: Specifies a list of connections that the Configurator will skip when it imports connections.

Debugging un-success imported resources in log files

Configurator log

You can check import process of Identify Configurator in Configurator_yyyy_mm_dd in "IdentifyLogs" logs folder. For example: C:\IdentifyLogs


FaultyImportData log

Identify Configurator also generate "FaultyImportData_[TenantID]" folder which is content faulty log files with name [IdentifyResource]_FaultyResult.json conrespondence for failure imported resources.

For example: Users_FaultyResult.json, Groups_FaultyResult.json, ProtocolConnections_FaultyResult.json, AuthenticationConnections_FaultyResult.json and so on.

Specifications inside faulty resource log file :

  • Action is SKIP for resource items were ignored when import.

  • Action is CREATE for resource items were failed when creating import.

  • Action is UPDATE for resource were failed when updating import.