Tuesday, August 6, 2013

Taking reverse proxy functionality into account within your software architecture

Within the Java project I am currently working on we had to deal with lots of security related questions and challenges.

The project itself is a Java project created with the following stack:
- Spring MVC (Controller)
- Apache Wicket (frontend)
- Spring / Spring Data / Apache CXF (Business & Service Layer)
- Hibernate (Model)

The application itself is deployed within a high-available environment.

One of a list of system architectural decisions we made was to handle all of our SSL trafic not within the application servers itself (using apache mod_ssl), but instead move it to the load balancer which is placed within the DMZ and actual acting as a reverse proxy.

This design has several advantages, both technical and from a maintenance point of view:

  • The SSL certificates and private keys are centralized on the reverse proxy service which simplifies key management. Not every application server within your application server cluster has to be polluted with SSL code and logic. In this way the responsibility and maintenance of this PKI management stuff can most of the times also move from project to hosting provider of your application.
  • The proxy server can terminate the SSL handshake and traffic from the proxy server to the application server cluster can be done using plain HTTP. This will lead to an improved performance of your application logic.
  • Upgrades of application servers can be done more easily. Switching to a new application server only requires reconfiguring the reverse proxy server to point to the new application server.
  • Improved security of your total application landscape when using a reverse proxy within a DMZ.
The message what I want to address is that you have to look further than only your software architecture environment, and also take the total system architecture including DMZ into account!!!!

Thursday, November 1, 2012

Access to XmlStore files from within Ws-App java code

Today I needed to have access from within Java Ws-App code to an XML definition located within the XML Store.
Within a Cordys BPM those webservices are available and can be easily drag and dropped into your BPM, but if you need this within your java code it can be easily accomplished by executing a Soap request.

public class XmlStore
    final String NS_CASEMNGT_INST = "http://schemas.cordys.com/casemanagement/instanceadministration/1.0";

    public static int getXMLObject(String userDn, String key)
        int retVal = 0;
        int response = 0;

            // Build up the request to send.
            String[] paramNames = { "key" };
            Object[] paramValues = { key };
            SOAPRequestObject sro = new SOAPRequestObject(NS_CASEMNGT_INST , "GetXMLObject", paramNames, 

            // Set the proxy user if passed on
            if (StringUtils.isSet(userDn))

            // Send the actual request.
            response = sro.sendAndWait();

            // Find the response document
            retVal = XPathHelper.selectSingleNode(response, "//xs:old/*", Constants.xmi);
        catch (Exception e)
            throw new CustomException(e, Messages.ERROR_GETTING_FILE_FROM_XML_STORE, key);
        return retVal;

And in the calling function you have than something like this:
Int xmlstoreObject = XMLStore.getXMLObject(BSF.getUser(), "/nl/project/xmlstore/xmlfile.xml");

Don't forget in your calling code to clean-up the NOM element by using the 'Node.delete(node)' function.
Otherwise memory leaks can be easily introduced.

Retrieval of user details of logged-in Cordys user

Retrieval of the user details of the logged-in user can be easily done using the BSF and LDAP build-in utility functions.

Below an example of a Java function which retrieves the ‘Full User Name’ and ‘email’ adres which is shown within the Cordys User Manager. Furthermore, it retrieves the ‘Full Organization Name’ from the Cordys Organisation Manager.

  * This method returns the raadpleger details of the logged-in user.
  * @return  A string array with 3 values:
  *  - value 1: Full Name of the logged-in user
  *  - value 2: Email of the logged-in user
  *  - value 3: Full Name of the organization of the user
 public static String[] getRaadplegerDetails()
    String[] raadplegerDetails = new String[3];

String userDN = BSF.getUser();

    String orgDN = BSF.getOrganization();
LDAPDirectory ldir = LDAPDirectory.getDefaultInstance();
        LDAPEntry userLdapEntry = ldir.read(userDN);
        LDAPEntry orgLdapEntry = ldir.read(orgDN);

        // Check if it's an organizational user or an authenticated one.
        LDAPAttribute attr = userLdapEntry.getAttribute("objectclass");
        String[] classes = attr.getStringValueArray();
        boolean found = false;

        for (String className : classes)
            if ("busorganizationaluser".equals(className))

                found = true;

        // Read the entry of the authenticated user if the passed on DN was of an org user.
if (found)
            String authUser = LDAPUtils.getAttrValue(userLdapEntry, "authenticationuser");
            userLdapEntry = ldir.read(authUser);

        // Set the Full User Name
        raadplegerDetails[0] = LDAPUtils.getAttrValue(userLdapEntry, "description");
        // Set the Email
        raadplegerDetails[1] = LDAPUtils.getAttrValue(userLdapEntry, "mail");
        // Set the Full Organization Name
        raadplegerDetails[2] = LDAPUtils.getAttrValue(orgLdapEntry, "description");
       return raadplegerDetails;

Monday, March 28, 2011

Show 'Cordys Management Console' graphically on Linux

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

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

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.

Thursday, February 10, 2011

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/">
      <m:GetLastTradePrice xmlns:m="Some-URI">

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">
    <ans1:eid xmlns:ans1="http://ws.fusion.com/">eid</ans1:eid>

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.

Wednesday, January 26, 2011

Connect to CARS via external LDAP Client

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

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.

Tuesday, January 4, 2011

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.