The SDI V7.2 Server API:
Remote clients, such as the Administration and Monitoring Console (AMC), can identify the TDI server they are talking toby setting a unique ID for the server. Remote clients can connect to an SDI server based on server's IP address, port, the unique ID. AMC registers every server with a unique ID, so that an SDI server cannot be registered more than once by mistake or intentionally. When assigning IDs manually, users must ensure that different IBM Security Directory Integrator servers have distinguishable IDs.
We set the unique server ID in either global.properties or solution.properties...
The server API throws an exception message when no password is supplied or if when the password entered is wrong. This can occur if we use a password protected Config without using a password.
Remote Method Invocation (RMI) is enabled by default. RMI requires Secure Socket Layer (SSL) for client authentication. Sample keystore and truststore files are deployed.
If a config instance does not completely load the configuration file when the server API makes a call, the server API returns a null object. You can add a time-out interval by editing global.properties and adding property:
The Default interval is two minutes. If the config file does not load within the time interval, an exception is thrown.
Properties are keyword:value pairs of parameters kept outside your configuration files (configs), stored in External Properties files. This enables us to keep confidential information like passwords outside of the Config files. The global.properties file is the main configuration file for SDI. Properties are defined in the global.properties file or in the solution.properties file. The solutions.property file is a writable copy of the global.properties file and is used when the server is started from the solution directory. If a solution directory different from the installation directory is specified during installation, then a copy of the global.properties file named solution.properties is created in the SDI solution directory.
We can access properties from a script using entry functions like getProperty() and setProperty(). Get and set methods work directly with property values. Entry objects can also contain properties. Attributes store data content. Properties store parametric information.
Property and Attributes can be any type of Java Object. Properties do not show up in:
Properties set in any properties files form a baseline for the entire SDI installation for all users on that computer. However, if your Solution Directory is different from the installation directory, you can have a set of text files in your Solutions Directory that mirror their counterparts in the installation directory. A property listed in any of those files override anything set in any of the global installation property files, including the global.properties and solution.properties files. A Java property set inside a Config file takes the highest precedence, and overrides anything in a global property file or the property files in the Solution Directory.
We can specify the Solution Directory in multiple ways:
In any other case, the first time you e the IBM Security Directory Integrator Server, it makes a copy of all the property files into your Solutions Directory (it does not overwrite these files if they already exist).
We can now tailor these files to our particular needs, without affecting the property files in the installation directory. The files remaining in the installation directory continue to form a baseline configuration for other instances of IBM Security Directory Integrator.
The global.properties file is copied to a file called solutions.properties in your Solutions Directory. Other files, like Log4J.properties and the files in the amc and serverapi folders are copied under their own names
For documentation purposes, the original global.properties file from the installation directory is copied to the solutions directory (/IBM//TDI/V7.2/etc); this file is not used for any other purpose.
Solution properties typically override global properties and are found in a file in your solution directory called solution.properties. The solution.properties file is by default a copy of the global.properties file, and you should edit the solutions.properties file when configuring SDI, because it is read last out of all the properties files. You can delete properties in your solution.properties file and add property configuration statements that you specifically want to override the global.properties defaults.
Java properties are variables and settings of the Java Virtual Machine (JVM). Java log (Jlog) file properties are shown in Useful JLOG parameters.
A Java property set inside a Config file takes the highest precedence, and overrides anything in a global property file or the property files in the Solution Directory.
| Property | Default value | Description |
|---|---|---|
| javax.net.debug | none | Sets debug mode for the JSSE provider. |
| com.ibm.di.javacmd | none | Overrides the Java interpreter. |
| com.ibm.di.installdir | none | Uses this path to the Java executable file when running AssemblyLines from the Configuration Editor. |
| com.ibm.di.jvmdir | TDI_root/jvm | Defines the directory path where the JRE that SDI uses is installed. |
| com.ibm.di.server.maxThreadsRunning | 500 | Sets this number of threads SDI. Must be set higher than 3 to have any effect. |
| com.ibm.di.server.securemode | false | Sets the mode in which SDI is running. (standard or secure) |
| com.ibm.di.server.keystore | testserver.jks | Names the keystore of the Server's SSL certificate. |
| com.ibm.di.server.key.alias | server | Names the key alias of the Server's SSL certificate. |
| {protect}-api.keystore.password | server (encrypted by default) | Provides the password for the server API keystore. Added in SDI 7.0. |
| {protect}-api.key.password | Provides the key password. If not specified, uses server keystore password. Added in SDI 7.0. | |
| com.ibm.di.server.encryption.keystore | testserver.jks | Names the keystore of the server encryption key. Added in SDI 7.0. |
| com.ibm.di.server.encryption.key.alias | server | Provides the key alias of the server encryption key. Added in SDI 7.0. |
| com.ibm.di.server.encryption.keystoretype | jks | Provides the type of the keystore that hosts the key used by the server for encryption. Added in SDI 7.0. |
| com.ibm.di.server.encryption.transformation | RSA | Names the cryptographic transformation used by the server for encryption. Can be set to either "RSA" (public key encryption) or to some secret key transformation. Added in SDI 7.0. |
| com.ibm.di.server.fipsmode.on | false | Enables or disables FIPS standards in SDI. If this property is set to true, SDI runs in FIPS-compliant mode. |
| com.ibm.di.default.bind.address | * | The default bind address for the whole SDI Server - the components and the Server API |
System properties are stored in the System Store instead of being stored in an external properties file such as solution.properties. Certain system properties and Java properties are read-only. These system properties are shown in the respective Property Stores (for example, System Store). Attempting to modify these read-only properties has no effect. See also Chapter 12, System Store
SDI supports persistent storage (that is, storage of objects that survive across JVM restarts), by means of a tightly-coupled relational database, the System Store. The product deployed by default to implement the system store is a relational database implemented fully in Java, known as Apache Derby, and previously known as Cloudscape.
The System Store stores the following objects:
The default location of SDI System Store database, in network mode, is your Solution Directory. Therefore, you can have a System Store for each of your Solution Directories.
To share a single System Store across all the Solution Directories, replace $soldir$ value with the actual TDI_install_dir in the property...
...in global.properties file and solution.properties file, if already created.
When you create a Solution Directory, update the following properties in the solution.properties file with unique values to avoid conflicts with other Solution Directory settings:
The following example describes the effect of specifying the same value for com.ibm.di.store.port property across multiple Solution Directories.
There are two solution directories (soldir1, soldir2) with the same com.ibm.di.store.port values (1527, 1527), and with unique api.remote.naming.port values (1099, 41099).
When you start server on soldir1, the server starts on port 1099 and System Store on port 1527, inside soldir1.
When you start Server on soldir2, the server starts on port 41099 and connects to the System Store, which is already listening on port 1527 inside soldir1
Password store and User property stores are types of system stores.
The Password Store is an external repository that stores a value which results from changing the value for a password syntax component. The password protection mechanism is directly related to the configuration windows offered to the user. The configuration windows, or forms, contain descriptions of each parameter and its syntax. One type of syntax is password which causes the Configuration Editor to use a password text field for editing. This external repository for passwords is configured in the Properties page in the configuration editor (Password-Store) and is specified in the configuration file for the current SDTI solution. If no such property store is configured the password is saved in clear text in the configuration file.
If a default password store is configured, a unique property name is generated the first time a protected/password parameter is saved. This key is used as the key in the password store. The same property name is written to the configuration file as a standard property reference. When the value is later retrieved, standard property resolution takes place to retrieve the actual value from the password store.
If a Password Store is specified, a unique key is generated for the password and the password is saved encrypted in the Password Store under that key. In the configuration file, the password is referenced only by that key. User property stores The User Property Store is a System Store table used for maintaining serialized Java objects associated with a key value. This is where persistent component parameters and properties (such as the Iterator State Store) are maintained, as well as any data you store. The System Store implements User property stores as one of its three types of persistent stores for SDTI components. For information on SDTI user interfaces that allow you to select properties from a property store.
The System Store can also be configured to use other multi-user RDBMS systems, as opposed to using the bundled database, Apache Derby. This is done by specifying appropriate SQL Data Definition Language (DDL) statements and driver parameters as system properties in global.properties or solution.properties. Example statements, commented out, are present in the distribution version of global.properties in the TDI_install_dir/etc directory, for the supported configurations of IBM DB2, Oracle and MS SQL*Server.
It is also possible to take advantage of suitable templates built in to the Configuration Editor, by going to the appropriate SDI Server document. Right-click on the Server in the Servers pane, and select Edit system store settings. The Server System Store header in the window is a context-sensitive menu; it has selections for Derby Embedded, Derby Networked, Oracle, DB2, MS SQL*Server 2005+ and IBM solidDB®.
Note: A System Store can also be configured on a per-project basis in the Configuration Editor; these settings are then stored in the Config file when the project is exported, and take precedence over the System Store defined for the Server.
JDBC Driver parameters provide a path to the database; additional properties are used to specify tailored SQL for certain operations IBM Security Directory Integrator must be able to perform in the System Store. Multiple SQL statements can be specified per property. Each separate statement should be terminated with a semicolon. An example property could be (note that for display purposes. All statements for a given property should be on one line):
...where {0} => is replaced by the Table name; and {UNIQUE} => is a special variable which can be used to generate a unique name based on the current system time. The following section lists example connection parameters and statements for each of the supported RDBMS systems.
Usage of Oracle requires that you drop the JDBC driver client library, ojdbc14.jar, in the TDI_install_dir/jars directory.
JDBC connection parameters
Where itimdb is the SID of the database to be used as System Store.
Create table statements