You may use the embedded PostgreSQL database supplied with Identikey Server, or another ODBC-compliant database.
12.2.1 What is Stored in the Data Store?
The following information is stored in the data store:
Digipass User accounts
Digipass and Digipass Application records
Digipass configuration records (Policies, Components, Back-End Servers, Reports and Report Formats) Identikey Server Configuration information
12.2.2 Domains and Organizational Units
Image 41: Domains and Organizational Units
Domains and Organizational Units are included in the ODBC database in a way that mirrors the data structure used by Active Directory.
Organizational Units are designed to hold User accounts and Digipass records. They allow grouping of Users according to department, job function, or other criteria. They also allow Digipass to be allocated for
Auto-Assignment to single or multiple groups of Users. Both Domains and Organizational Units can be used to limit administrators to a group of Users and/or Digipass.
12.2.3 Location of Digipass Records
When a Digipass is assigned to a User, it is moved to the same Organizational Unit as the Digipass User account to which it is assigned.
Note
When a User account is moved to an Organizational Unit, all Digipass records assigned to it will also be moved.
A Digipass record assigned to a User cannot be moved - the User account must be moved.
Unassigned Digipass records may be allocated to various places in the Organizational Unit structure:
Master Domain
During installation, a default domain is created. Digipass are imported to the Master Domain, and may then be moved to other domains and Organizational Units.
Organizational Units
If an Organizational Unit structure is used in the database, Digipass can be moved either into the exact Organizational Units where the User accounts to which they will be assigned are located, or into a few key Organizational Units in the hierarchy where they may be assigned to Users in lower level Organizational Units.
When looking for an available Digipass to assign to a User, the Identikey Server will first look in the same Organizational Unit as the specific User account, if the User account belongs to an Organizational Unit. The Search Upwards in Organizational Unit hierarchy option, when enabled, allows the Identikey Server to search in parent Organizational Units and the Digipass Pool container. This option may be set at the Policy level for system searches (eg. Auto-Assignment and Self-Assignment) or at the time of the search for manual assignment.
Note
The Identikey Server will always find or assign the closest available Digipass record to the selected User record(s).
If the User account being assigned a Digipass does not belong to an Organizational Unit, the Identikey Server will look for an available Digipass in the domain which does not belong to an Organizational Unit.
12.2.3.2 Typical Digipass Location Models
Domain Root
Digipass records may be stored in the Domain Root while unassigned.
This option allows a centralised point of access for assignment of Digipass. It also requires less calculation and high-level administration - Digipass records are all stored in one area and there is no need to manually move records or calculate the exact number of Digipass required for each Organizational Unit or group of Units.
Administrators must belong to the Domain only (not an Organizational Unit) to assign Digipass from the Domain Root.
Image 42: Digipass Record Locations – Domain Root
In the diagram above, the Identikey Server searches upwards through the Organizational Unit structure for available Digipass to assign to a Digipass User in the Organizational Unit B1. Because no available Digipass are found in B1, it searches in B, then in the Domain root.
The administrator account must be located in the domain root (no Organizational Unit) in order for this model to work successfully.
Note
The Search Upwards in Organizational Unit hierarchy option must be enabled for this model to function correctly.
This option is simplified if an Organizational Unit structure is not used in the database. User accounts and Digipass records may all be stored in the Master Domain. The Search Upwards in Organizational Unit hierarchy option does not need to be enabled in this case.
Parent Organizational Units
Unassigned Digipass can be kept in key Organizational Units, and made available to their lower level Organizational Units.
Image 43: Digipass Record Location – Parent Organizational Unit
In the diagram above, the Identikey Server can search in the parent Organizational Unit for available Digipass.
Administrators will need to belong to the parent Organizational Unit.
Note
The Search Upwards in Organizational Unit hierarchy option must be enabled for this model to function correctly.
Individual Organizational Units
Digipass can be loaded or moved into each Organizational Unit where and when they are required. If all Digipass in the Organizational Unit are assigned, more Digipass will need to be moved in manually by a Domain Admin before they can be assigned.
Image 44: Digipass Record Location s – Individual Organizational Units
In the diagram above, unassigned Digipass are stored in the exact Organizational Units in which they will be assigned.
Administrator accounts belonging to the Organizational Units A1 and A2 have administration privileges in their own Organizational Unit only.
Note
The Search Upwards in Organizational Unit hierarchy option does not need to be enabled for this model.
Combination of models
Digipass may be stored in the Master Domain as well as some or all Organizational Units. If no unassigned Digipass records are found in the Organizational Unit, and the Search Upwards in Organization Unit hierarchy option is enabled, the Identikey Server will search upwards to the Domain Root and search in the Digipass Pool for an available, unassigned Digipass record.
12.2.4 Permissions Needed by the Identikey Server
Identikey Server will require either:a database administrator account for the database, ownership of the VASCO tables, or
permissions to insert, remove, read and modify rows in VASCO tables.
See the Administrator Reference for more information. This is set up automatically in the case of the embedded database option.
12.2.5 Database Command Line Utility
This utility has to perform several tasks that are needed at various times during installation and upgrade, or afterwards for maintenance. Some of the commands are run automatically by the installation program, while others are run manually. The commands that are run automatically can be run manually also, for example to troubleshoot why the installation is not succeeding.
Command Description
addschema Modify the database structure to create the required VASCO tables.
checkschema Check that the required database modifications and/or table name remappings have been completed.
dropschema Remove all database schema modifications from the database.
Table 7: DPDBadmin commands
12.2.6 Additional ODBC Databases
A synchronized backup database may be set up for the Identikey Server. This helps to ensure continuous service if the main database fails. The synchronization can be a shadow database, a mirror or a replicated copy.
The required synchronization must be set up according to the instructions provided by the database vendor. It is strongly recommended to minimize the synchronization delay.
Once the database and any synchronization is set up, create a Data Source Name for the new database and add it to the Identikey Server Configuration GUI.
Image 45: Additional ODBC databases
See the Database Connection Handling topic in the Administrator Reference Guide for more information.
12.2.7 Multiple Identikey Servers
If more than one Identikey Server is installed on the system, some additional setup may be required.
Multiple Identikey Servers Using Same Database
If more than one Identikey Server is using the one ODBC database, no additional setup steps are required. A backup database should be considered.
Image 46: Multiple Identikey Server Using Single Database
12.2.8 Replication
When multiple Identikey Servers are in use each with their own database, they can be configured to replicate data changes between them, to keep all database synchronized.
12.2.8.1 Common Scenarios
Primary and Backup Identikey Servers
The most common, and most basic, replication setup is used when a company has two Identikey Servers – one primary, to which all authentication requests are customarily sent, and a backup Identikey Server for use when the primary server is busy or unavailable. Replication is usually set to occur very frequently.
Image 47: Replication between a Primary and Backup Identikey Server
Primary, Backup and Disaster Recovery Identikey Servers
This scenario is often used when a company requires an offsite disaster recovery Identikey Server and database.
Image 48: Replication between Primary, Backup, and Disaster Recovery in Identikey Server
12.2.8.2 Other Scenarios
Other replication scenarios may also be used. For example, a company may have three Identikey Servers, all replicating to each other. This may keep data up to date better than a simpler replication chain.
Image 49: Replication between three Identikey Servers
Or, a company might require two Primary Identikey Servers, each with a backup Identikey Server, and add in an extra replication link to speed up data communications:
Image 50: Complex Identikey Server Replication Scenario