Connect to CARS via external LDAP Client

Problem: How do we connect to Cordys Admin Repository Server (CARS) via an external LDAP client.

How:
Before starting to give a solution for this it is good to know that CARS by default uses one-way SSL for the CARS authentication. This can be changed  of course by adapting the default installation configuration of CARS, but this is not recommended.

Note: changes this can be done by adapting the property: ‘cars.sslmode ‘ withinin the file <instance-name>.properties, which is located within the Cordys install dir.

default CARS settings

Steps to be taken in order to connect to CARS via an external LDAP client

1. First check if you can connect using the Content Manager of the Cordys Management Console into CARS.

2. If step 1 succeeds (login successfull), take over the configuration of the connect screen of the Content Manager and use this information to connect via your external LDAP client (e.g. JXPlorer).

Using this way you are able to connect with your preferred LDAP client to the CARS OpenLDAP implemenation. Another nice LDAP client to use is Apache Directory Studio.

Have fun.

An overview of SSL Authentication

Background on SSL

The industry-standard Secure Sockets Layer (SSL) protocol, which uses signed digital certificates from a certificate authority (CA) for authentication, is used for secure communication.

SSL provides encryption of the data that is exchanged between the applications. Encryption makes data that is transmitted over the network intelligible only to the intended recipient. Signed digital certificates enable two applications connecting in a network to authenticate each other's identity. An application acting as an SSL server presents its credentials in a signed digital certificate to verify to an SSL client that it is the entity it claims to be. An application acting as an SSL server can also be configured to require the application acting as an SSL client to present its credentials in a certificate, thereby completing a two-way exchange of certificates. Signed certificates are issued by a third-party certificate authority for a fee. Some utilities, such as those provided by OpenSSL, can also issue signed certificates.
SSL uses public key encryption technology for authentication. In public key encryption, a public key and a private key are generated for an application. Data encrypted with the public key can only be decrypted using the corresponding private key. Similarly, the data encrypted with the private key can only be decrypted using the corresponding public key. The private key is password-protected in a key database file (keystore) so that only the owner can access the private key to decrypt messages that are encrypted using the corresponding public key.

SSL Authentication

The SSL authentication process uses certificates that are issued by a certificate authority. The same process applies if the certificates are issued by an certificate generation utility or if self-signed certificates are used.

The figure below illustrates the steps that authenticate the identity of an application:

To establish an SSL connection:

1. An application acting as an SSL client contacts an application acting as an SSL server.
2. The SSL server responds by sending the signed certificate stored in its keystore to the SSL client. A CA certificate contains identifying information about the CA that issued the certificate and the application (owner) that presents the certificate, a public key, and the digital signature of the CA.
3. The SSL client uses the corresponding CA certificate stored in its keystore to verify the digital signature on the certificate.
4. In addition to verifying the signature on the certificate, the SSL client requests the SSL server to prove its identity.
5. The SSL server uses its private key to encrypt a message.
6. The SSL server sends the encrypted message to the SSL client.
7. To decrypt the message, the SSL client uses the public key embedded in the signed certificate it received, and thereby verifies the identity of the owner of the certificate.

If the SSL server is set to use two-way SSL authentication (client authentication), it then asks the SSL client to verify and prove its identity, and the same process described above is used to verify the identity of the SSL client to the SSL server.

One-way SSL authentication

One-way SSL authentication enables the application operating as the SSL client to verify the identity of the application operating as the SSL server. The SSL-client application is not verified by the SSL-server application.

Two-way SSL authentication
In two-way SSL authentication, the SSL client application verifies the identity of the SSL server application, and then the SSL server application verifies the identity of the SSL-client application.

Two-way SSL authentication is also referred to as client authentication because the application acting as an SSL client presents its certificate to the SSL server after the SSL server authenticates itself to the SSL client.

If you are using self-signed certificates, you must create and install the self-signed certificate and private key on the SSL-client and SSL-server applications, then extract the certificate from the keystore of each application and add it to the keystore of the other application.