Project Settings
The Project Settings screen is the starting point for any DATPROF Privacy project. It enables you to select a connection to a target database and to import or synchronize metadata.
Connection Editor
In order to mask (parts of) a database, a connection to the database is required. This connection is used for the importing and synchronizing the metadata and will be used to execute the masking functions on that database.
A database connection can be specified, selected and saved in the Connection Editor. The left side of the screen displays the saved connections. The right side of the screen shows the connection details of the connection that is used for the current project, this connection is known as Project Connection. A selected connection becomes the actual Project Connection by pressing “Use this connection”.
Managing your sensitive data when contacting DATPROF
It’s entirely possible that when depending on our staff for support of our systems, the topic of transferring your project file to DATPROF comes up. Luckily, due to the way we design our software we don’t handle the data within your database, and a project doesn’t contain any sensitive data about your datasets. However, because it’s possible to store and save the connection data to databases in our software a project file can contain privacy or security risk bearing connection data. Therefore, if you would like us to look at one of your project from a support perspective we strongly urge you to delete any existing connection data in the Connection Editor.
As this is information we have no desire to have within our system, and could contain sensitive information, we will prune this information in any event this is attached erroneously to protect our data privacy conformity. Nevertheless, it falls to the submitter of any ticket to be wary of privacy sensitive data and remove it where possible.
When defining a connection, the following parameters are required:
Microsoft SQL Server
Basic Connection Details
Database type: Microsoft SQL Server
Host: Host name or IP-address of the database server
Port: TCP port on which the database server is listening
Instance: Instance name of the database server
Database: Name of the target database
Authentication Types
SQL Server supports many types of authentication. In order to support as many as possible, the user can select which authentication type to use in this drop-down box. Authentication types can vary from simple password authentication to more complex Azure specific authentication types. Some authentication types require additional JDBC- or ADO.NET connection properties, but even when not required the user may supply extra properties to account for database specific configurations.
SQL Server Authentication
Description: A simple username & password authentication against the database.
Extra properties required: None aside from default.
Windows Authentication
Description: Windows authentication checks the computer name of the client connecting to the database for validation.
Extra properties required: None aside from default.
Microsoft Entra Managed Identity
Description: Microsoft Entra Managed Identity works by checking a specific client ID against the database for access, and is used to connect to SQL Server on the Azure cloud. For more information please refer to the Microsoft documentation: https://learn.microsoft.com/en-us/azure/azure-sql/database/authentication-azure-ad-user-assigned-managed-identity?view=azuresql
Extra properties required: None aside from default.
Microsoft Entra Service Principle
Description: Microsoft Entra Service Principle works by checking a service principal ID and service principal Secret to connect a user to the database. For more information please refer to the Microsoft documentation: https://learn.microsoft.com/en-us/azure/azure-sql/database/authentication-aad-service-principal?view=azuresql
Extra properties required: None aside from default.
Microsoft Entra Password
Description: Similar to the SQL Server Authentication, but using login details configured in an Entra ID environment. Uses a simple username + password combination.
Extra properties required: None aside from default.
JDBC & ADO.NET Properties
In order to handle specific database configurations, it’s possible to supply extra JDBC or ADO.NET connection properties. These are properties which are always passed on when connecting to the database, and are configured in a Property + Value pair. By default, Privacy contains a few JDBC properties, used to connect to SQL Server databases. Unless specifically needed, we don’t recommend removing these.
JDBC Properties Overview
The above link refers to Microsoft documentation, which is subject to change.
ADO.NET Properties Overview
The above link refers to Microsoft documentation, which is subject to change.
Oracle
Database type: Direct for connection through the interface, or ConnectionString to use a connection string.
Username: Oracle Database Username
Password: Oracle Database Password
Host: Hostname or IP-address of the database server
Port: TCP port on which the database server is listening
SID / Service: Unique database identification, which type you need to supply is dependant on database configuration.
Connecting via a connection string
With this option an Oracle Tnsname entry can be provided to connect to the database. In order to do this, a valid Tnsnames.ora must exist.
You can also specify a complete Oracle Connection description which allows you to use all the features of Oracle Connection Manager.
Example:
(Description=(ADDRESS=(protocol = TCP)(host = datprof-server)(port = 1521))(CONNECT_DATA = (SERVICE_NAME=datprofora1.localdomain)))
PrivacyConsole.exe can use an existing ConnectionString option but you cannot specify it on the command line.
DB2 for Linux, Unix and Windows
Database type: IBM DB2 for Linux, Unix and Windows
Host: Hostname or IP-address of the database server
Port: TCP port on which the database server is listening
Database: Name of the target database.
DB2 for i
Database type: IBM DB2 for i
Host: Hostname or IP-address of the database server
Database: Name of the target database
Username & Password: credentials to access the target database
DB2 for z/OS
Database type: IBM DB2 for z/OS
Username & Password: credentials to access the target database
Host: Hostname or IP-address of the database server
Port: Port over which to connect to the database
Database: Name of the target database
Connecting through the connect descriptor
When connecting to a DB2 z/OS database, it’s possible for the user to supply a JDBC connect string instead of supplying individual values. In some situations, this is required (such as when the mainframe database requires a certificate to connect to it). For a complete overview of the syntax for DB2 z/OS connect strings, please refer to the following page of the IBM documentation:
JDBC connect string example:
Syntax:
jdbc:db2://<database_host>:<port>/<database_name>:sslConnection=true;sslTrustStoreLocation=<full_path_to_jks_file>;sslTrustStorePassword=<trust_store_password>;
Example:
jdbc:db2://My-Favourite-Database:8102/PRODUCTION:sslConnection=true;sslTrustStoreLocation=C:\users\me\certificates\db2Zstorecert.jks;sslTrustStorePassword=changeit;
PostgreSQL
Database type: PostgreSQL
Username & Password: credentials as used in the database
Host: Hostname or IP adress
Port: Port number of the database server
Database: Name of the database to obtain metadata from and execute the run against
MySQL / MariaDB
Host: Hostname or IP address
Port: Port number of the database server
Database: Name of the database to obtain metadata from
Username: Database user
Password: Password for database user
Azure SQL
Currently, in order to connect to an Azure SQL database the user should use the “MS SQL Server“ project connection option. In future releases, this is subject to change. For information about JDBC properties, please refer to the SQL Server chapter of this page.
Database type: Microsoft SQL Server
Host: Hostname or IP-address of the database server
Port: TCP port on which the database server is listening
Instance: Instance name of the database server. With a default Azure SQL deployment, this can be NULL.
Database: Name of the target database
Test, Save, New
Using the Test button the selected connection can be tested. This option will try to connect to the database using the specified connection details. The result is shown to the user.
The Save password option ensures that the login information is stored and does not need to be re-entered in future sessions.
The Save button ensures that the specified Project Connection is stored in the list of saved connections.
All connections are stored in the file “Privacy_connections.lst” in “<Windows User>\AppData\Local\<PrivacyInstallationFolderName>\privacy\”
The New button will clear the input fields allowing the user to define a new connection. You can also modify an existing entry and save it as a new entry.
Whenever a connection is saved in your project, new connections are restricted to the Database type you saved.
Importing meta data
Through the button Import metadata (or using the menu option Project → Import and synchronize → Import metadata wizard), a wizard for importing meta data of the specified database is started. Importing the metadata through this wizard consists of three steps:
Selecting the schemas and tables
Selecting the relations (foreign keys)
Importing the specified metadata
Selecting the schemas and tables
During this first step, the user can select the tables to be imported. The screen consists of two parts.
The left part shows the metadata available in the database. In the drop-down box (top-left) the schema containing the tables can be selected. In the list below the user can select one or more tables which will be imported.
The right part shows the tables selected to be imported.
With the single arrow, the selected tables are added to the list of tables to import. The double arrow will add all tables from the selected schema into the list of tables to import.
The Next button moves the wizard to the next step.
Selecting relations (foreign keys)
This next dialog allows the user to select the foreign key relations (FK's) to import. This dialog has the same format as the previous dialog. The list of available FK’s are derived from the selected tables. Again, the user can select one or more FK’s and add them to the list of FK’s to import.
Normally you would select them all.
The Next button moves to the next step.
Importing the specified metadata
The last dialog of the wizard allows the user to begin the import of the selected metadata (tables and FK's). By clicking on Start, the application will retrieve the selected metadata from the database.
The progress of the import can be monitored with the Progress Bar.
Pressing Logging will unfold a dialog that prints log lines. This logging will help to resolve any errors that may occur during the import.
Synchronizing metadata
The Metadata Synchronization Wizard helps the user to process any changes to the data model of the target database, ensuring that masking can be executed against such changes. Synchronization can take place through a DME file or an ODBC database connection (Project Connection).
The information in the database is the primary source.
Manually added Primary Keys using "Toggle Primary Key" are removed.
Manually added Translation Keys using "Toggle Translation Key" are still available.(since v3.8.3)
The Synchronization wizard does not distinguish between self-defined Foreign Keys and Foreign Keys removed from the database. They are both marked for deletion in the wizard.
A Field order change will trigger the synchronization process.
In this step, using an ODBC connection is the regular way of importing/synchronizing meta data. Functionality of DME files is handled elsewhere in this documentation.
The following screen shows a summary of the differences between the metadata from the target database and the metadata already imported into the application.
If you decide to exclude certain metadata from an initial import, they will show up here too. The system cannot differentiate between “new” differences, and ones that have already been acknowledged by the user and accepted during an initial import. This synchronisation simply compares the metadata present in the project to what a new request for metadata to the database returns.
Changes may include tables, columns and FK’s. These can be added, changed or deleted.
By clicking Next, a dialog will be opened for each type of change, where the user can decide whether to process the change in the project.
The last screen allows the user to process the selected changes in the project.
The progress of the synchronization can be monitored with the Progress Bar.
To show the log file made during import, press Logging. This logging also provides input for resolving any errors that occurred during synchronization.