Validating XML Signature is relatively simple to setup on the Vordel Gateway. Here are the steps:
Step 1: Open the Vordel Policy Studio. Connect to the Gateway you wish to configure your policy on. Either connect directly or login through Policy Director (Policy Director allows you to push out policies to a number of Gateways at once).
Once you connect, choose "Edit Active Configuration".
You will see the screen below:
New Web Services are registered in the "Web Service Repository" which is accessed under the "Policies" group on the left-hand-side.
Step 2: Right-click on the "Web Service Repository" and choose "Register Web Service". Note that the Web Services are arranged in groups, and you can rename these groups. In the screenshot below you can see that we've created a group called "B2B Web Services" and one called "Internal Web Services".
Step 3: Select your WSDL (either via URL, file, or use
the UDDI interop with registries such as HP Systinet) and then walk through the wizard. Choose the location to deploy your virtualized service. Out of the box, there is a set of services called "Default Services" on port 8080 in the Vordel Gateway, but you can rename this or change the port. You can also add a new service group (e.g. called "SSL Services") with a different listening interface (create the new services, then right-click and choose "Add interface").
Don't check the box right now to "Secure this Web Service" (that's what we'll do next). You'll then see a "Summary" screen in the wizard, which says what path the Virtual Service has been deployed on. Take note of this path, but note that you can always see it again by right-clicking on the service and choosing to "Quick Edit" it. Press OK and then press the "Deploy" button on Policy Studio to deploy. Now open the WSDL in the browser. Note that
the Vordel Gateway will automatically virtualize the service hostname in the WSDL.
Step 4: Right-click on "Policies" in the Vordel Studio and select "Add Policy". If you already have created a contained to contain your policies, you can right-click on your container and make your policy there. Note that containers are a way to group policies together, e.g. for importing and exporting them together, but don't affect the running of the policies.
Call your new policy "Validate Signature"
Step 5. Drag in a "XML Signature Verification" filter, which you can find in the "Integrity" group in Policy Studio [tip: in the searchbox above the list of filters in Policy Studio, start typing "Signature" and it will narrow down your choices to just those which include signature functionality). Configure it as shown below:
When you drag in the filter on to the policy canvas, it is initially gray because it is not being used yet. Right-click on this filter and choose "Set as start". Now it is no longer grayed out. However, it is outlined in red because it requires an input (the messages) which it is not getting at the moment. For it to get this input, it must be "wired up" to policy that is receiving a message through a listening interface.
Step 6: In Policy Studio, look under "Policies" and then "Generated Circuits" to find the service you've registered in Step 3. Double-click on the filter called "Service Handler for '
'. Then open the "Message Interception Points" tab. Under "Before Operation-specific Policy" press on the "..." button to choose the policy you made in step 5 to do Signature Validation. Once it is mapped, you should see the mapping set. Make sure you press the "Deploy" button on the Studio toolbar to deploy this policy.
Step 7: To test this service, we'll use SOAPbox, which is Vordel's free Web Service testing tool. We will import the Virtual Service WSDL which you obtained from Step 3. In SOAPbox, press on the Import WSDL button (on the toolbar) and import the Virtualized WSDL from the Gateway.
Step 8: You'll see a sample message created for you in SOAPbox. Send the message through to the Vordel Gateway, by pressing the green triangular "play" button on the toolbar of SOAPbox. This message will be blocked because it has no signature. Note that you can customize the response message, since in a production system it is not usual to return a SOAP Fault to clients.
Step 9: View the blocked message in the Vordel Gateway's Real-Time Monitoring by pointing a browser to :8090/ and then clicking on "Real-Time Monitoring". Note that you'll have to login as a user with a role which allows viewing of Real-Time Monitoring. The screen is shown below:
Step 10: In SOAPbox, choose "Security" then "Sign Request" on the menu. Under "Signing Key" you can simply choose the sample key which ships with SOAPbox (called "CN=SOAPBoxConfig"). Under the "What to Sign" tab, choose the "Xpath" sub-tab and then choose "The SOAP 11 or SOAP 12 Body". Leave the other settings as they are, and press "Finish". You should now see the signature in your message in SOAPbox. Send the signed message through and it will be validated successfully , as shown below:
Other steps: In Studio, note in the "certificates" group that you can then check the trust of the certificate from the signature (i.e. check that its issuing CA is trusted). you can also validate the certificate against a CRL, an OCSP responder, or an XKMS service. To do these steps, drag one or more of these filters after your Validate XML Signature filter and drag a green line from the Validate XML Signature filter to it, indicating that you wish to check the certificate after you have checked the signature. Note that the "certificate" attribute is populated after the signature filter runs, and it then is passed to the certificate validation filters which require it.
