Show 'Cordys Management Console' graphically on Linux

Problem:
How to open the 'Cordys Management Console' on a Cordys Linux server in a graphical way.

How: 
In order to achieve this we need 2 tools:
- Xming for Windows
- Putty

Actions:
1. Install XMing for windows with default options

2. Configure Putty with X11 forwarding within your session to your server

3. Login and test using the 'xclock' command

4. Start the 'Cordys Management Console' within putty. This is found within the 
Note: we use Cordys CU-17 and there the cmc.sh file is located within the bin directory of the BOP-4 install.

Understanding the SoapAction mystery

For a current project I was asked why a provided WS-I Basic Profile 1.1 compliant webservice wasn't using the SoapAction attribute.
Therefore, I will explain the usage of the SoapAction keyword here.


The SOAPAction header in SOAP 1.1 has given many developers and implementors fits about understanding its purpose. I suggest that this is because of the two very different ways in which SOAP can be used.


Below the statements of the specifications
The SOAP 1.1 specification says this about the HTTP SOAPAction header.
"The SOAPAction HTTP request header field can be used to indicate the intent of the SOAP HTTP request. The value is a URI identifying the intent. SOAP places no restrictions on the format or specificity of the URI or that it is resolvable. An HTTP client MUST use this header field when issuing a SOAP HTTP Request"


The WS-I Basic Profile says this about the HTTP SOAPAction header

Interoperability testing has demonstrated that requiring the SOAPAction HTTP header field-value to be quoted increases interoperability of implementations. Even though HTTP allows for header field-values to be unquoted, some implementations require that the value be quoted.

The SOAPAction header is purely a hint to processors. All vital information regarding the intent of a message is carried in the envelope.

The presence and content of the SOAPAction header field can be used by servers such as firewalls to appropriately filter SOAP request messages in HTTP. The header field value of empty string (”") means that the intent of the SOAP message is provided by the HTTP Request-URI. No value means that there is no indication of the intent of the message.


So if you’ve got a SOAP message like this one:

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">    <SOAP-ENV:Body>       <m:GetLastTradePrice xmlns:m="Some-URI">           <symbol>DIS</symbol>       </m:GetLastTradePrice>    </SOAP-ENV:Body> </SOAP-ENV:Envelope>

Then you see that the intent of this message being sent is the meaning of “GetLastTradePrice”. 

Given this use of SOAP (with the method in the SOAP envelope), it should not be surprising at all that developers are confused, as it appears as though the value of SOAPAction is redundant.

As the SOAPAction is transport specific -an HTTP header field, you should try to avoid it's use when authoring WSDL files for your new services, especially if you plan to use other transports for the same service.
There are only a few usecases where you really need it: it's when you are using overloaded methods (if your language of choice permit it).
The Key to this problem is to understand the relationship between the WSDL and the wire format, and to realize that the name of the wsdl:operation is not necessary present on the wire.

We can imagine a soap envelope like the one below in which no explicit operation is defined.

<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema">   <env:Body>     <ans1:eid xmlns:ans1="http://ws.fusion.com/">eid</ans1:eid>   </env:Body> </env:Envelope>

From the wire format above, once cannot which operation is called. In order to route such a message, you need extra information - it's the purpose of the SOAPAction header in the list displayed below.

User-Agent: Oracle HTTPClient Version 10h SOAPAction: "urn:lookupEmail" Accept-Encoding: gzip, x-gzip, compress, x-compress Content-type: text/xml; charset=UTF-8 Content-length: 302

The main reason the SOAPAction is used by most Web Services framework is as a performance optimization. It provides a key to lookup the operation where the message should be routed at, without to have to process the SOAP payload (the soap:body).

To sum up:

• use an empty value if you can.
• use it when you are using overloaded methods; the QName of the top-level element of the soap:body can be used to uniquely identify the operation that should process the incoming message

Note that this tips is specific to SOAP 1.1 and will not apply moving forward, as the routing attribute will be factored in the addressing header.

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.