Not logged in | Login
HTTPBCWSIT Mutual Certs
The Mutual Certificates Security mechanism adds security via authentication and message protection. Client and service certificates are used to sign and encrypt messages to ensure integrity and confidentiality, respectively. Using mutual certificates require that a keystore and truststore file be configured for both the client and server sides of the application.
The examples implemented on this page can be downloaded as NetBeans projects:
The following instructions create a project that uses the service-invocation mechanism available to BPEL processes. By using BPEL (and thus the JBI environment) to implement the "client" that talks to the service, the HTTP BC can be used as a consumer proxy to demonstrate how WSIT options are configured for JBI clients.Note In creating a client in this fashion, these instructions create, essentially, a second service. There is the target service defined in the previous section, and there is this triggering service that starts a BPEL process that, in turn, calls the target service.
1. Ensure that the target service, created in the previous section, has been built and deployed before continuing.
2. Create a NetBeans BPEL project. This project will implement the triggering service.
3. Import the description of the target service into the BPEL project.
4. Define (create the WSDL) of the trigger service. The SOAP binding is utilized here so that the trigger service can be executed from the SOAP tester available to JBI Composite Application projects.
5. Compose a BPEL process that invokes the target service.
For diagnostic purposes, the BPEL process will concatenate the service call's response with a fixed string literal. The presence of this string literal in the test output serves as verification that the service call was conducted by the BPEL process.
1. Build the BPEL project.
2. Create a JBI Composite Application project. Add the BPEL project to it.
3. Build the JBI Composite Application project. This step is mandatory before WSIT options can be configured, because the building process generates the required service assembly information.
1. Access the Service Assembly node in the Composite Application project, to load the project's assembly information into the Composite Application Service Assembly (CASA) editor.
Note that the "inbound" WSDL port (upper port in the diagram) represents a consumer endpoint for the triggering service, not the target service.
The actual object of interest for assigning WSIT options is the "outbound" WSDL port, which represents the provisioning endpoint to the target service. To configure WSIT options for this port, first clone the port so that the CASA editor will permit the modification of the port.
The assembly graph displayed by the CASA editor is obtained from information culled from the BPEL project, which the Composite Application project does not modify. The act of cloning a port creates a local, modifiable copy of the BPEL project information, in the Composite Application project.
2. Once the port is cloned, access its context menu again and choose to Edit Web Service Attributes / Client Configuration.
3. The WS-Policy Attachment dialog appears. Since Mutual Certificates, the WS Security mechanism used by the target service, requires Keystore and Truststore information, this service client needs to provide these configuration information. Click on the Keystore... and Truststore..._ buttons and provide the required parameters
4. Save changes.
1. If the target service needs to be deployed, do so now.
2. Build and deploy the client Composite Application project.
3. Navigate to the Test node of the Composite Application project, access its context menu, and choose to create a New Test Case.
4. Once the Test Case is created, its input file is shown. Populate it with data.
5. Access the Composite Application project's context menu and choose to Test. Since this is the first time the test is run, the test will fail because there is no prior output against which to compare the test result. Answering No to the prompt(s) will deposit the test result into a subnode in the Test Case subtree. Edit the node to see the result.
The output of this test instance was (reformatted for readability):
<?xml version="1.0" encoding="UTF-8"?> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://schemas.xmlsoap.org/soap/envelope/ http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Body> <m:TriggerResponse xmlns:m="http://j2ee.netbeans.org/wsdl/TriggerService"> <part1 xmlns:msgns="http://j2ee.netbeans.org/wsdl/TriggerService" xmlns="">Response___echo_MutualCerts_TestMessage1</part1> </m:TriggerResponse> </SOAP-ENV:Body> </SOAP-ENV:Envelope>