This article is going to help you setup the Configurator for Safewhere*Identify
Launching the configurator
The Configurator can be launched from Start >Identify>Safewhere*Identify 5.0 Configurator in Windows Start Menu.
Setup & Customize
Initially the Configurator will check that you have all prerequisite components installed on your server. If not, you must close the configurator and install those missing components before trying again.
The first thing to specify in the Configurator is the database server that is used to store the tenant management database. The tenant management database stores information on the settings of tenant installations; like version, tenant ID, whether the tenant is part of a NLB environment, and so forth.
If you just wish to manage this database on the currently used server, you can leave the server name Empty.
If you wish to set up the SQL Server with Integrated Security, then you do not need to input any info in the username and password fields.
If you have access to multiple SQL Servers, you can choose among these from the Server dropdown or simply type in the SQL Server that you wish to use. Please notice that you may have to wait a little for those drop down options to show up, typically takes 10-15 seconds to find all servers in your network. If you are choosing a different server than the local one, you will also need to specify SQL server account for that database.
Once having specified where the installation information of your tenant must be (or has been) stored, the system will be able to check if any tenant instances already exist. In the following step, it will therefore offer a number of actions that can be taken on tenants; including creating, deleting and upgrading them.
- Create new instance: When you wish to set up a new tenant.
- Replicate: It is possible to install tenants in a load balanced environment (on multiple servers). The process for this is simply to run both installer and configurator on another server as well. Make sure that you choose the same tenant management database on all servers onto which you install tenants (first step of the installer), since this database is used to ensure that individual installations of the same tenant can work well together and are using the same database. When you run the configurator and it knows that you have tenants running on other servers than the current one, it will propose the option “Replicate”. Simply choose the tenant that you wish to make another installation of and the system will, during the next steps, ensure that you are only to update those settings that are allowed to be different between the tenant installations. For more information please go the Tenant Replication.
- Delete an instance: When you wish to delete one of the tenants already installed. The dropdown will list all those tenants found in the tenant management database specified in the prior step.
- Upgrade existing instance: If you have upgraded Safewhere*Identify (which is done by running the system Installer with a newer version of Safewhere*Identify), then all Tenants that have not yet been upgraded to this newest version, will be listed in this drop down. Simply choose a tenant to upgrade it to the newest installed version of Safewhere*Identify. Please notice that tenants have no problem running on older versions of Safewhere*Identify, even when other tenants on the same installation may have been upgraded. Upgrading tenants from a working version always bares some risks of malfunction; so many companies choose not to upgrade tenants that are working well and do not require any new features.
- Delete all instances: This is a quick way to remove all tenant instances instead of doing this one at a time using “Delete an instance”. This option is only shown when we have more than one installed tenant.
- Upgrade all out of date version instances: Upgrade all tenant instances instead of doing this one at a time using “Upgrade an instance”. This option is only available when there is more than one installed tenant.
- Uninstall identify completely: This is basically the same feature as “Delete all instances”. However, also the Identify databases – Identify, Identify Audit, Identify Session, and Identify Cache – will be removed when this option is chosen. This option is only shown no tenants are installed on a different server from the one running the configurator.
Since both delete and upgrade actions will be executed immediately, the next part of this article will focus on explaining the tenant creation process. So let us assume that “Create new instance” was selected and the ‘Next’ button clicked.
At the “specific settings” step, we specify the following info about the tenant id, client name and its default language which will be used for Identify*Runtime:
Enter tenant id: The name you wish the tenant to be known as. This ID is used several places in the setup of the system, as proposed default values for domain name and application pool names. Since it will be used as proposed name for domain, you must not use spaces, symbols, or characters/numbers other than a to z and 0 to 9.
At the next “General info” step, we will input:
- Enter database schema: After entering a tenant id at the previous step, you will notice that the database schema is proposing the same name for the database schema. The database schema is the name that the tenant database will be saved as on your database server.You must not use spaces, symbols, or characters/numbers other than a to z and 0 to 9.
- Enter or choose database server where the tenant will be installed: If you just wish to manage this database on the currently used server, you can leave this dropdown empty. However, leaving this field empty is not recommended since it will mean that you will not be able to replicate this tenant onto another server. Please notice that once clicking on this dropdown, you may have to wait a little, since it typically takes 10-15 seconds to find all servers in your network.
- Select database authentication: specify the database authentication method. You can choose between SQL Database Authentication and Windows Authentication (Note: In case the database server you select is AzureSQL, only option “SQL Database Authentication” is available)
- Enter database login name: Username for the selected database server. If Windows Authentication is selected, user is able to enter the user name directly or find it using the ‘Search’ button. For domain users, it should be in the format <domain>\<user>. Besides, the specified user will be set as Identity for this tenant application pool in IIS.
- Enter database login password: Password of the above user.
- Session state mode: Session state supports several different storage options for session data. And since this verion 5.0, we only have: InProc mode which stores session state in memory on the Web server and this setting is not shown on UI any longer.
- Generate default value for tenant: This checkbox will populate the fields in the IIS step of the configurator with default values, which usually makes it easier on the user to insert the correct values. The default values are useful when you wish to run a local test copy of the system with all the default settings. When setting up a production implementation, you need to take more care in choosing the correct settings. Here is screenshot on IIS step when this checkbox is unchecked :
Once you click the ‘Next’ button, the “Audit log information” step displays
- Select audit database provider: either select MSSQLServer or MongoDB.
- Enter server name or host: fill in the database server name or IP address.
- Enter database login name: fill in the username to login to database server or use default value generated by the Configurator (only for MongoDB)
- Enter database login password: fill in the username to login to database server or use default value generated by the Configurator (only for MongoDB)
- Enter database name: read-only, generated by Configurator
- Enter port: fill in the port to connect to database server or use default value generated by the Configurator
- Enter connection timeout: fill in the timeout for connection to Audit database or use default value generated by the Configurator.
You are now ready to specify settings in IIS.
Server IP: The unique IP address on which the tenant’s sites (admin, runtime and service) will be hosted.
Port number: The port number of the server of which the tenant’s sites (admin, runtime and service) will be hosted.
Domain name: The DNS domain where the tenant implementation is placed (thus, it’s the Host Name that is specified in the IIS Site Bindings property sheet). E.g. if you set the domain to “test1.safewhere.local”, then the federation login should be redirected to test1.safewhere.local and the admin web site will be placed at https://test1.safewhere.local/admin.
Bind SSL certificate method: In order to bind the SSL certificate chosen in the earlier step up against the new sites, choose the first of the two offered options. If you wish to make the binding in IIS later, choose the second option.
Site application pool: This setting is just a quick way to set the Application pools names for the admin, runtime and service sites.
Admin site application pool: The name of the admin site as it will appear in the application pool. It may be set to use the same application pool as the runtime site.
Runtime site application pool: The name of the runtime site as it will appear in the application pool. It may be set to use the same application pool as the admin site.
Service site application pool: The name of the service site as it will appear in the application pool. It may be set to use the same application pool as the admin site.
Configure certifications of the wizard you need to specify the certificates that will be used by Safewhere*Identify to identify itself to external parties. There are two certificates that must be specified: SSL certificate and signing certificate. The SSL certificate is used to ensure secure transactions between web servers and browsers, whereas the Signing certificate is used to sign federated requests and responses between Safewhere*Identify and external Identity Provider and Relying Party.
Default certificate: Safewhere*Identify comes with default certificates making it quick to set up for testing purposes. Since these certificates does not identify you as a unique user, please do not use them for actual production works.
Auto-generated certificate: Auto-generate is used for testing when Safewhere*Identify is not set up using the installer, but rather set up manually.
Import from file: Let you import your certificate file to the server’s certificate store and apply to the tenant.
Password: When importing a new certificate to your server’s certificate store, you will be required to specify its password in order to activate it.
Select from server’s certificate store: If the needed certificate is already stored in the server’s certificate store, you can choose it using this dropdown.
Import certificate to Trusted Root Certification Authorities: This field is just a supporting field for uploading a root certificate which identifies the other certificates as trustworthy (if this does not already exist on your server).
On clicking the ‘Next’ button, you will reach the step where the installation is ready to be executed. Click “next” again to start this process.
After the execution page, you have already reached the last step. A direct link is provided here for immediate access to the Identify*Admin site of the new tenant. The default credential for accessing to the admin page is as follows:
Since version 4.0, we have enabled the Window security log. Users need to follow the proposed steps specified here before logging on to the tenant for the first time.
Besides, we improve the backup and rollback feature on the Identify flow so in case something breaks during upgrading/created, the upgrading tenants will not die. You can find its more details at here
It is possible to install tenants in a load-balanced environment (on multiple servers) by simply run both installer and configurator on another server. The following section specifies how tenant replication is done.
The general processing steps are the same as when creating a new tenant. However, there are a few constraints of which you should be aware:
- Only tenants that have been upgraded to the newest installed version of Identify are shown in the ‘Replicate’ dropdown list.
- When replicating a tenant using ‘Windows authentication’ as database authentication, you will be presented with the following message after choosing the language and the client name.
- When replicating a tenant using ‘Inproc’ as Session State, you will be presented with the following message after choosing the language and the clientname.
- At the ‘General info’ step, all info of the tenant being replicated will be loaded. In case database authentication is set to ‘Windows authentication’, you will need to input the password for the user login for the replicated server.
- At the “Audit log information step”, it will load the info of the tenant being replicated. So just click ‘Next’ to go to next screen.
At the ‘IIS setup’ step, you will need to specify the same domain name as used by the tenant being replicated
- At the ‘Certificates’ step, you will need to specify the same SSL certificate and the same signing certificate as used by the tenant being replicated.
The remaining steps are the same as when creating a new tenant.
Since version 5.0++, we support to the feature Identify database backup before the tenant upgrade is executed.
When this setting is enable, we will handle the Identify database backup at the 16th step on the upgrading process. This backup will be stored at the folder”Backup” of the SQL server localtion in the database server, e.g If you are using the SQL Server 2014 C:\Program Files\Microsoft SQL Server\MSSQL12.SQLEXPRESS\MSSQL\Backup
For the user context who will be in used for this database backup, he is selected at the step:
And to do the backup permission, he must fulfill the following:
+ If his server role is sysadmin, he can do the database backup as well as run the transaction.
+ If his server role is public and he ‘s got access to database as db_owner, he must have the access to the msdb on User Mapping with the TargetServerRole
Note: In case the in use database is AzureSQL, this option is not available and user will receive this message when doing the tenant upgrade