Business Process Management

First of all, how does client authentication with a certificate work in SOAP?
It is not enough to send the certificate like a passport as a proof of identity. Because the certificate can be copied and distributed, it could be stolen from any intercepted message. Therefore the certificate is not the proof of identity.

The trick about the secure identification is more sophisticated. It is important to understand that the certificate contains a public key while the private key is securely stored in the client's environment. The client encrypts a piece of the SOAP message with its private key and sends this encrypted information to the service provider along with the certificate. This encrypted information is called the signature of the client. It is not important which part of the soap message is used to create the signature. The xml string to be encrypted only has to be sufficiently long to make sure that it is difficult to decrypt the signature.
Now this signature is the proof of the identity, because it proofs the possession of the private key.

The service provider can decrypt the signature with the public key from the certificate. If the decryption is successful, he can be sure that the client possesses the private key. The identity is proofen.
This is the strategy behind  asymmetric encryption a.k.a. public key encryption.

A very recommendable tutorial to implement this with Axis2 and Rampart is already available under https://wso2.org/library/3415. I trust that this tutorial works, but I wanted to configure it better and hit some problems which are not solved yet.

These are my issues:

• I want to authenticate one way only (client -> server), because the server has already been authenticated via https. But in the policy definitions I have not understood how I can distinct between
  

1. Policy definition for incoming message. This defines the level of security which the service expects from incoming messages. This definition shows up in the WSDL file.
2. Policy definition for outgoing messages in the service provider's policy. This is the configuration for what the SOAP header of the service response should contain.
   

• I want to separate keystore and truststore. I think it is a bad practice in the java world that the private key and the public keys of others are in the same file. You have to trust the application that they take out the correct key out of this file to send it to clients.

Once I have figured this out and made my example work, I let you know.

After reading the book about Webservice Security like mentioned in my last post, I want to try out my knowledge in practice.
Transport Layer Security is the most basic security mechanism to start with. This should be a no-brainer since it is the task of the application servers to handle this problem.
This means, that the transport channel is encrypted and the identity of the webservice provider server is checked. Standard https also means that the identity of the webservice consumer will not be checked.

In short:

• The application server of the webservice consumer checks the certificate of the application server which hosts the webservice provider
• The application server of the webservice provider does not request a certificate from the webservice conumser's server.

My ingrediants for my test implementation:

• Jetty server, version 7 as application server for the webservice provider
• Tomcat server, version 6 as application server for the webservice consumer
• Self signed certificates. This is sufficiant if your webservice calls stay inside one company network.
• Existing webservice implementations for provider and consumer, implemented with Apache Axis2. Check this post to see the architecture.

1.0 Setup Jetty Application Server (WS Provider) to open an https port

For the webservice provider's server to accept requests via https, I followed the instructions from codehouse. The basic steps are these:

- Generate certificate which contains identity and a public key
- Sign the certificate yourself (The alternative would be a to let it signed by Verisign, GeoTrust, etc. which would cost a lot of money)
- Add the certificate to a keystore. This keystore doesn't exist after a new installation of jetty.

After you have followed these instructions, the jetty server sends a certificate to every requestor which contacts the jetty server on its https port. The certificate has the function of a passport which is signed by an organization who anybody trusts. (If you would have let it be signed by Verisign, GeoTrust, etc.). The webservice consumer's application server has to decide upon this certificate if it trusts this application server . How does  the consumer's application server make this decision?
The answer is simple. If the server has this certificate in it's truststore, then it decides to trust this issuer of the certificate.
This brings us to the next step:

2.0 Setup Tomcat Application Server (WS Consumer) to trust the WS Provider's server

 

2.1 Get certificate from the WS provider's server

The easiest way to get the certificate the WS provider's server issues, is to call the https port with your webbrowser. Just call the https URL for the wsdl file. You webbrowser will ask you if you want to trust the issuer. This question is again, because your browser doesn't know the organization which signed the certificate. (Because you didn't let it be signed by VeriSign, GeoTrust, etc.) Tell you browser to trust the issuer and it will connect you to the requested URL.
With Firefox, you can click on the identity sign next to the URL.

 

Then get the certificate by following this path: More Information > View Certificates > Detail > Export. Save it as a .pem file and name if jetty_certificate.pem.

2.2 Add the certificate to tomcat's truststore

Since tomcat doesn't have a truststore by default, create a new truststore file for tomcat and add jetty's certificate:

keytool -import  -alias jettykey -file jetty_certificate.pem -keystore tomcattruststore

2.3 Modify Tomcat Scripts for Tomcat to use the truststore

I modified catalina.sh by adding the information to the Java Options:

CATALINA_OPTS="$CATALINA_OPTS \

-Djavax.net.ssl.trustStore=/opt/tomcat6/tomcattruststore \

-Djavax.net.ssl.trustStorePassword=mypassword"

After this modification, you have to restart tomcat.

3.0 Modify Webservice Consumer Implementation

As you might know, Axis2 generates you a Stub-Class for every Service. This Stub-Class has two constructor's, one is empty and the other one has an argument to hand over the webservice endpoint address.

3.1 Change Webservice endpoint address

Obviously you should never use the empty constructor because an SOAP Endpoint address can always change, for example when the service is deployed on a new server. When I developed the webservice consumer I used simple java properties to store all parameters of the endpoint address in a text file. Check here:

monitor.webservice.endpoint.hostname=localhost

monitor.webservice.endpoint.port=8443

monitor.webservice.endpoint.protocol=https

monitor.webservice.endpoint.path.status=/monitor/services/Status.StatusHttpSoap12Endpoint/
Therefore it is very simple to modify the webservice code to use the new https connection. 
Just edit the port and the protocol parameters and deploy the service again. 

3.2 Modify axis2.xml

Without https and and without any other security, no axis2.xml file was necessary in the webapp project. But for https I had to add axis2.xml to WEB-INF/conf to define the https transport receiver. This xml fragment in axis2.xml made it work:

    <transportReceiver name="https" class="org.apache.axis2.transport.http.AxisServletListener">
        <parameter name="port">8443</parameter>
    </transportReceiver>

That's it. Now the webservice communication is running via https. This was the first and most simple step towards secure webservice communication. The next and more challenging steps will be to implement Client(=consumer) Authentication and Message Layer Security like XML Signature and XML Encryption.

Webservice security is my current field of interest because from my experience I see a fast increase in security questions for distributed computing.

Webservices have been mostly a technique to integrate heterogenous systems and technologies. These were within one secure network and therefore security was not a big issue. But two trends change this:

1. Webservices become more important for B2B communications. This communications uses the internet. Secure transportation and client/server authentication is always necessary. Even though the data might not be very confidential in many cases, attacks might harm the business continuity.
2. Cloud computing puts business critical applications outside the company network. Business critical and confidential information has to be transported through the interntet. VPN connections are usually not possible with cloud solutions.

 
Here is one example:
During a project I was implementing the webservice connectivity between SAP and Oracle CRM on Demand  for a large global corporation. Oracle CRM on Demand is a CRM cloud solution. It stores the revenue calculations and revenue forecasts, customer prospects etc. This is very confidential data for every company.
The communication with Oracle CRM on Demand is done via webservices.

The security consits of two techniques:

1. Transport Layer security through SOAP over https. One way authentication as usual.
2. Client authentication and authorization through a simple login webservice. This service asks for username and password and returns a token which has to be used as a session identifier in the URL of all subsequent webservice calls.

This is all. Would you consider this as secure? Let's transform this example to a more tangible scenario:

• Let's assume, the revenue data is written in books and not in it systems.
• The data is not in a cloud but in a house.
• I assume further, that besides the standard interfaces, the cloud is very secure. Therefore we image that the house which contains the books is Fort Knox. You have no chance of entering besides through the standard gate.
  

With these assumptions, the security concept of Oracle CRM on Demand / Fort Knox looks like this:

The people which approach Fort Knox know for sure that it is Fort Knox and not a different house which pretends to be Fort Knox. They know it because there is a certificate at the gate which is very believable.

Furthermore, the persons which come to and leave Fort Knox and  protected by the so called 'https security corporation' which accompanies them on their way. This makes sure that the persons are not attacked and their goods which they bring to or bring from Fort Knox cannot be stolen on the way.

But now let's have a look at the people which approach Fort Knox. They have to present a simple peace of paper which has a username and password on it. If both are correct, the guard will let them through into the house and they can look at all books.
Only when somebody comes three times with a peace of paper which contains the same username but different password and all password are wrong, then the guard will change the password for this user. But one person can come unlimited times and try different usernames and passwords. The guard will never become upset and will never call the police.

Furthermore, the security of Fort Knox knows how many usernames they have issued. But they don't know how often they were copied. Therefore they don't know how many people have access to Fort Knox. Because they never check the identity of the people which try to enter and not even of the people which do enter.
They don't care if the person is a friend or a rival. Anybody can enter with a copy of the paper.
Don't forget that the person which gets into Fort Knox cannot only look at the books, they can also destroy books or bring new books. But nobody checks if the new books are correct. Is is not clear if these are the same books which the sender gave to the messenger person.
Because don't forget that the messenger person has a long journey to bring the books from the sender to Fort Knox. He has protection while he is walking on the street, but he has to stay overnight in several hotels. Inside the hotels he has no protection. Bandits can exchange or edit the books while the messenger person is sleeping in a hotel. Or the bandies can create a copy of the books while the messenger is at lunch in the hotel's restaurant. All the revenue data is written in clear text in the book. They can just put in on a mobile copy machine.
Once the message arrives in Fort Know, nobody checks the integrity of the books. Nobody knows if anybody did read the books. They just put them into the shelves.

Obviously, this company would not organize its security like this if the data wouldn't consist of these intangible bits and bytes and if the gate security concept of it systems would be easier to understand. At least they would check the identity of people which enter their library of confidential data. At every company gate you have to present your identification. But not at the virtual company gates. At least since the companies outsource their IT systems.

It is easy to talk smart, but it is not easy to implement all desired security into webservice communication. Therefore I will  try to implement a simple webservice communication with Apache Axis2 in Java which is protected by Transport Security, Authentication and Authorization and Message Layer security like XML Signature and XML Encryption.

 

Finally, I have made  the last decision to complete my Open Source BPM Image. One component was clearly missing: An ESB.
Intalios BPM Solution has two possibilities to create connectivity solutions to other systems: JDBC and Webservices. The JDBC development is very comfortable and the creation of webservices works fine. But in the real world, most applications are not accessible via webservices. You need an ESB with which you are able to connect to applications and offer this connection as a service.

I have tried out several open source ESBs and finally decided for Glassfish ESB. Although I have not yet understood all the capabilites of this ESB and are not able to compare the capabilites to all other Open Source ESBs, I have decided for Glassfish ESB for one reason: It offers a graphical development environment. I think it is not up to date any more to develop services by writing XML by hand. Maybe I am spoiled by some commercial ESB solutions. But once you are used to mapping values by drag&drop, it is hard to develop service in a text editor again.

To complete the ESB solution, I have installed Apache ActiveMQ, too. A good messaging component is always helpful.

So here is the overview of my Open Source product stack on my BPM Virtual Image.

 

My next task is to provide a common database installation for Intalio and Glassfish ESB on the image. Both solutions have their own derby database by default. But this is not a solution for a long-term operation scenario.

With the initial setup of Intalio Community Edition, the user management information is stored in the server/var/conf/security.xml file. This works fine but it not usable for a real world environment.  

So LDAP is the most obvious choice. I installed openLDAP on my Ubuntu 10.04. That was a real nightmare. There is no straight forward way and many people have the same problem. Only after I have succeeded to install openLDAP, I found out that there is an easy way to provide LDAP for Intalio Server.

Intalio offers an Apache Directory Server in a web application. So here is the easy way:

 

1. Install a Tomcat Server

It is not recommendable to install the ApacheDS webapp on the tomcat on which intalio runs, because LDAP should be started before the Intalio server, otherwise you will get exceptions.

Therefore I installed a Tomcat version 6 and changed all the ports of the standard configuration in conf/server.xml to avoid collisions.

 

2. Deploy ApacheDS webapp

After downloading the Apache Directory Server webapp from the address http://www.intalio.org/public/maven2/org/intalio/tempo/apacheds-webapp, I deployed the war file through the Tomcat Web Application Manager webinterface. The application couldn't start because log4j was missing. After copying a log4j jar into the WEB-INF/lib folder of the webapp, I was able to start the application through the Tomcat webinterface.

During this startup, this ApacheDS application imports the ldif files which are located in its WEB-INF/classes folder. Afterwards, all standard users which are in the security.xml file are in the LDAP database too.

 

3. Edit the Intalio Security Provider

 You have to inform Intalio server somehow that it is supposed to use LDAP now. Do this by editing the file server/var/config/securityConfig.xml. Uncomment the LDAPSecurityProvider and comment the SimpleSecurityProvider. Then it will look like this:

<!--
<bean id="securityProvider" class="org.intalio.tempo.security.simple.SimpleSecurityProvider" init-method="init">
        <property name="configFile">
            <value>${org.intalio.tempo.configDirectory}/security.xml</value>
        </property>
</bean>-->
     
<bean id="securityProvider" class="org.intalio.tempo.security.ldap.LDAPSecurityProvider">
        <property name="propertiesFile">
            <value>${org.intalio.tempo.configDirectory}/ldap.properties</value>
        </property>
 </bean>

 As you can see, the settings for the LDAP access are in the file ldap.properties in the same directory. Have a look at the file, but all settings are correct for Intalio server to access ApacheDS already.

That is it. With these settings, the server will access ApacheDS to authenticate the users. Nevertheless, let's make the picture complete and let's add a new user.

 

 4. Add users via Apache Directory Studio

Get this application from http://directory.apache.org/studio/ and unzip it. There is no additional installation process.

Start it and add a connection with these settings:

Hostname	<your tomcat host>
Port	10389
Bind DB or user	uid=admin,ou=system
Password	secret

 Now you are ready to add new roles and users.

 

 

 5. Integrate user and role definitions in your process design.

Last, I want to show how you use this user and role definitions for the assignments of user tasks in a process. I will use my simple HelloWorld process.

In Intalio Designer, you can assign users tasks in the properties settings of the task. Choose 'workflow' and you can see the dialog to add users and roles for the assignment. It is not recommendable to assign tasks to users, because they usually constantly change. And you don't want to change you process implementation when employees change. Instead, assign roles to the tasks. Then you are flexible and can change the responsibilities for a task by editing your LDAP database.

Of course it is not only possible to assign responsibility for tasks in this static way. You can also assign a task to a role during runtime.  I have not tried it, but you can find a tutorial on the Intalio website.

 

 

 

For a simple transition from step A to step B you can easily draw a line between two steps. That works very well with both products. A more interesting use case to look at is a conditional transition.

Therefore I have added a gateway in my HelloWorld Example which is supposed to decide whether the process has to continue towards the human task 'UserConfirmation' or whether the process execution can go straight to the end step.

The condition is simple. After persisting the text which was passed to the process start step, the gateway step has to decide this: 

If the text equals 'HelloWord' then continue to the end step, otherwise go to the 'UserConfirmation' step, where a user has to confirm or change the text.

First let's have a look at how to implement this in Intalio Designer:

 

In the Mapper-tab of the gateway step, you can edit the condition. Therefore you open the view 'Mapper Palette' and choose the desired operators and functions. And Intalio really offers a lot of them.

You drag and drop an operator or function into the middle column of the mapper view. Afterward, you can assign values to the input parameters by drawing lines from variables in the left column. In the graph, I have marked the operator and function in the mapper palette, which I chose to implement the HelloWorld example.

 

Now, let's have a look how you can implement the same functionality in webMethods Designer.

 

In the properties view of the gateway, you can implement conditions on parameter values which are in the pipeline of the process. This is fairly simple, because webMethods offers only some basic operators and functions. That makes it even easier to implement a condition, compared to Intalio, but works only for some standard use cases. 

If you have a more complex condition, then you have to implement it in a service which is called prior to the gateway step. This services has to put the result of the evaluated condition into the process pipeline. The gateway is then able to evaluate this result with its basic operator.

Conclusion:

On this topic, Intalio is a step ahead of webMethods, because it offers more functions and operators. Of course, the higher functionality has the handicap of a higher complexity for implementation. But after you have tried it out one time, you wouldn't have problems with the good drawing procedure for implementing the conditions in Intalio.

Creating a process step which is supposed to connect to a database works fine with both products. Therefore I don't need to dig deeper into this topic. Both solutions provide a tool to generate a jdbc connector.
What they both do:

• Create a connection type
• Create a Query adapter on top of an existing connection type.

webMethods and Intalio provide a mechanism to assign parameters from the process pipeline to the placeholders in prepared statement. Intalio helps with a wizard in Intalio Designer and webMethods has its wizard in the webMethods Developer.

With some practice, you can easily create and connect a databse accessor to your BPM process within 10 minutes.

In my HelloWorld example process, the process step 'PersistText' stores the text from the input signature of the process into a mySQL database.

As you can see in the BPM graph, I have finished the little HelloWorld example. The input parameter for the process is one String, which gets stored in the step 'PersistText', afterwards the inputtext is presented to a user who can change the text and then submit it. The ouput of the process is the text which the user has submitted. Additionally, I added a gateway which adds an alternative path around the user interface.

 

 

 

Today I want to have a look only at the start event of the process and compare it to a webMethods process.

Let's start with Intalio this time.When you deploy the process onto the BPM Server (which is built upon a tomcat server) you can find some artifacts in the Axis2 container. Among schema files and the bpel file, you can find wsdl files. For every step in your process, Intalio generates an Axis2 webservice. And of course you can find a webservice for the start event.

 

 

That is a very convenient way to start your process. Just import the wsdl file into SoapUI and you are ready to test the process.


Now, how do you start a process in webMethods? You create a document type, make it publishable and syncronize it with webMethods Broker. Then you can just drag and drop this document onto your start event. That automatically generates a subscription onto this document type in webMethods Broker.

 

 

 

Then, you can publlish a document of this document type through the Designer to test your process.

 

 

That are two different approaches, but both work fine.
You start an Intalio process by calling a webservice, the webMethods process by publishing a document.
But I see two advantages for the webMethods way:

1. One Event can trigger several different processes.
2. How do you wait for the output of a long running process? That is no problem with the publish -and-wait implementation of webMethods. But I can't see how this could work for the http session of a SOAP Request. That much I still have to find out.