The TREX Java client is integrated into the application using TREX (for example, Content Management) as part of the J2EE Engine. This allows the application access to the TREX functions. The TREX Java client communicates with the TREX Web server (Windows: IIS/UNIX: Apache). The Web server then forwards requests to the TREX servers.
In most portal applications, the TREX Java client and Web server are behind the firewall. This means that you do not have to configure secure communication between these two components.
The TREX Java client and TREX Web server both need a certificate issued by the same CA in order to be able to communicate with one another securely.
The Java client needs a client certificate.
The Web server needs a server certificate.
Both components need the root certificate of the CA that issues the other two certificates.
The two communication partners can then encrypt their messages before sending them. The Web server can also authenticate the Java client using its certificate. The TREX Web server rejects requests from unknown communication partners.
Administrators provide the necessary certificates. They also configure the security settings on the TREX Web server and modify security-relevant parameters in the TREX configuration files.
In your enterprise, you have built up a public key infrastructure with your own CA that issues certificates.
You are working with any organization that offers the issuing of certificates.
The graphic below gives an overview of administrative tasks.
Provide a client certificate and the root certificate of the CA for the TREX Java client.
Provide a server certificate and the root certificate of the CA for the TREX Web server.
The Microsoft Internet Information Server (IIS) is used as the TREX Web server on Windows; on UNIX, the Apache Web Server is used. There are therefore two different procedures:
The Java client and Web server can communicate using HTTPS.