Java/Web Services SOA/HTTPS

Doing the communication using HTTPS

 
Hello World Demo using HTTPS communications
=============================================
This demo takes the hello world demo a step further 
by doing the communication using HTTPS.
Please review the README in the samples directory before
continuing.

Prerequisite
------------
If your environment already includes cxf-manifest-incubator.jar on the
CLASSPATH, and the JDK and ant bin directories on the PATH
it is not necessary to run the environment script described in
the samples directory README.  If your environment is not
properly configured, or if you are planning on using wsdl2java,
javac, and java to build and run the demos, you must set the
environment by running the script.

Building and running the demo using ant
---------------------------------------
From the samples/hello_world_https directory, the ant build script
can be used to build demo.
Using either UNIX or Windows:
  ant build
    
To remove the code generated from the WSDL file and the .class
files, run:
  ant clean

The demo illustrates how authentication can be achieved through
configuration using 2 different scenarios. The non-defaulted security
policy values are be specified via configuration files.
Scenario 1:
A HTTPS listener is started up. The listener requires
client authentication so the client must provide suitable credentials.
The listener configuration is taken from the "CherryServer.cxf" file
located in this directory.  The client"s security data is taken from
from the "InsecureClient.cxf" file in this directory, using the bean name:
"{http://apache.org/hello_world_soap_http}SoapPort.http-conduit". The
client does NOT provide the appropriate credentials and so the
invocation on the server fails.
To run:
  ant server
  ant insecure.client
Scenario 2: 
The same HTTPS listener is used. The client"s security data is taken
from the "WibbleClient.cxf" configuration file in this directory, 
using the bean name:
"{http://apache.org/hello_world_soap_http}SoapPort.http-conduit". 
The client is configured to provide its certificate "CN=Wibble" and
chain stored in the Java KeyStore "certs/wibble.jks" to the server. The
server authenticates the client"s certificate using its trust store
"certs/truststore.jks", which holds the Certificate Authorities"
certificates.
Likewise the client authenticates the server"s certificate "CN=Cherry"
and chain against the same trust store.  Note also the usage of the
cipherSuitesFilter configuration in the configuration files,
where each party imposes different ciphersuites contraints, so that the
ciphersuite eventually negotiated during the TLS handshake is acceptable
to both sides. This may be viewed by adding a -Djavax.net.debug=all 
argument to the JVM.
But please note that it is not adviseable to store sensitive data such
as passwords stored in a clear text configuration file, unless the
file is sufficiently protected by OS level permissions. The KeyStores
may be configured programatically so using user interaction may be
employed to keep passwords from being stored in configuration files.
The approach taken here is for demonstration reasons only. 

To run:
  ant server
  ant secure.client
Certificates:
If the certificates are expired for some reason, a shell script in 
bin/gencerts.sh will generate the set of certificates needed for
this sample. Just do the following:
        cd certs
        sh ../bin/gencerts.sh