Advanced Web Service Interoperability In Easy Steps

Enhancing your service/client with Security and Reliability

The work we have done so far has covered web service implementation. However, to make our example more realistic, we need to make sure of several things. It would be very bad if your bank order requests have been lost during transmission and you wouldn't know about it. Also, it would be wrong if banking orders are executed in a different order than you submit them. Reliability features of Metro will help us here, but the list of complaints against the basic implementation is longer.

From security perspective, we need to make sure that only certain users are able to submit the orders. Also, when they are sending the orders, we should make sure the communication is encrypted so that nobody can read what kind of banking orders we are submitting, and we need to use signing of messages to ensure that the message has not been tampered with on the route from service to client and back.

Performance is also important, so we'd prefer not to establish a secure session for each message, but establish only one secure session, send multiple messages during the session and then terminate it, or set a timeout when the session should terminate.

To help with these additional requirements for our service implementation, we'll use the WSIT NetBeans plugins, which are directly included in NetBeans Full or Web & Java EE bundles. To invoke the WSIT functionality for your web service, click the Advanced... button in the bottom of the Visual WS designer, or right-click your web service in project explorer window and select Edit WS Attributes action. You should see a dialog corresponding to Figure 7.

Figure 7. Quality Of Service Settings in NetBeans IDE 6.1

 

Reliability

Let's start with solving the first two complaints first. To make sure that messages are not lost on the wire, click the Reliable Message Delivery checkbox, as shown on Figure 8. Right below that, click Deliver Messages In Exact Order to solve the second complaint. That sets up the reliability features of project Metro. Close the dialog, redeploy the service BankApplication and the client, and submit several orders again.

Figure 8. Setting up Reliability and Ordered Message Delivery

If you look closely to your application, you might notice the dialog created one configuration file, called wsit-bankorder.service.BankOrderService under project's src/conf folder. The file includes the settings in the form of Policy expressions, understood by WSIT implementation.

With this setup, you can see that message communication has changed a bit. In the message log, you may find the messages contain new headers, such as those from Listing 7. Some namespace declarations are removed from there for more clarity.

Listing 7. Message Headers with Reliable Messaging turned on

<MessageID>uuid:eb7be0e5-00c4-40b1-a9f0-9557caadd9c5</MessageID>
<RelatesTo >uuid:fcd8cf00-3f97-49b6-a290-58fb7c8afdd5</RelatesTo>
<ns2:Sequence>
  <ns2:Identifier>uuid:bd42d7f6-56e1-47a7-ae63-772c691c5bf5</ns2:Identifier>
  <ns2:MessageNumber>1</ns2:MessageNumber>
</ns2:Sequence>
<ns2:AckRequested>

Presence of those headers means that Reliable Messaging is active. You might notice the Sequence identifiers and MessageIDs. Those are used to ensure proper delivery so that the Metro runtime knows which message to resend if it has been lost, and also how to order the messages correctly on receiving side.

 

Security - Service

Now focus on the security requirements. NetBeans allows you to secure your service in one step. Return back to the Quality Of Service dialog, choose Secure Service option as shown on Figure 9 and redeploy the application. That's all you need to do on service side to secure your service. If you try to invoke your client again, you'll see it fails because it does not specify required credentials for the service.

Figure 9. Setting up Security on service

For development purposes, NetBeans with Metro provides certificates to be used. These development credentials are used if you click Use Development Defaults checkbox, which is chosen by default. For your production purposes, you will need a real certificates issued by appropriate certificate authorities.

In the real world, security considerations are much more broad, so the default settings might not apply for your real life scenario. NetBeans IDE 6.1 defines several Security Profiles, which are designed for different security scenarios. The default profile is called Username Authentication With Symmetric Keys. The profile uses message level security, and protects your application for integrity and confidentiality, which means that the communication between service and client is encrypted and signed. With this profile, symmetric key cryptography is used – it relies on a single, shared secret key that is used to both sign and encrypt a message. Symmetric keys are usually faster than public key cryptography. For this profile, the client does not possess any certificate/key of his own, but instead sends its username/password for authentication. The client shares a secret key with the server. The shared, symmetric key is generated at runtime and encrypted using the service's certificate. The client must specify the alias in the truststore by identifying the server's certificate alias.

From other profiles, you may choose different security mechanisms with message level security or SSL transport, using SAML tokens, or using Secure Token Service (STS). STS profiles are used to introduce 3rd party into the client-service communication. Client authenticates with the 3rd party (STS provider), and further requests to the service are made using security tokens issued by the 3rd party.

Each security profile can be configured in detail through the configuration dialog. The settings correspond to the profile chosen, but for most non-SSL based security profiles you can specify the key lengths used (128-256bit), configure Secure Conversation and other settings. Secure Conversation is switched on automatically when Reliable Messaging is used, and improves performance of secure communication between service and client significantly where multiple messages are transferred. With Secure Conversation, the security context is established only once, and further communication happens using derived keys. One of the configuration dialogs is shown on Figure 10.

Figure 10. Security Profile configuration dialog

A complete description of the configuration, security requirements and possibilities would be enough for a book or two, so for further information you can consult the Metro documentation, where you'll find the list of security profiles with descriptions to easily find which profile match your needs.

 

Security – Client

After we secure the service, our client is not allowed to communicate with it anymore, because it requires credentials. To fix this, we need to let the client know about the new service capabilities. These capabilities are advertised in the service WSDL in the form of Policy assertions, such as those in Listing 8.

Listing 8. Policy assertions describing Reliability settings on service – Reliability enabled, Ordered Delivery enabled

<wsp:Policy wsu:Id="BankOrderServicePortBindingPolicy">
  <wsp:ExactlyOne>
    <wsp:All>
      <ns3:RMAssertion/>
      <ns7:Ordered/>
      <ns8:UsingAddressing/>
    </wsp:All>
  </wsp:ExactlyOne>
</wsp:Policy>

Right-click your WS client under the Web Service References node, and select Refresh Client. Choose also an option to replace service WSDL with new version in the next dialog. With this update, the client is aware of service security capabilities, but it still doesn't have the required credentials. To set them, right-click the client node again, and select the Edit WS Attributes action. The client Quality Of Service dialog is shown in Figure 11.

Figure 11. Setting up Security on client

For development purposes, select Use development defaults button, click OK, redeploy your client application and try to submit several banking orders again. Check the GlassFish log for the messages. You'll notice they are encrypted, and you can no longer read the real values being transfered.

The development defaults option automatically sets the required certificate aliases, and also creates and specifies the login credentials for wsitUser. Static specification of username credentials is not preferred in most security scenarios. For that purpose, you can verify or pass the credentials dynamically using callback handlers. To specify callback handlers, you need to switch the Authentication Credentials combo box from Static to Dynamic, and specify the location of your handler classes. More information about this type of authentication/verification can again be found in the Metro documentation.

Note: You don't need to change your service implementation at all to enable Reliability, Security, or other features!

Attachment	Size
figure1.png	69.91 KB
figure2.png	58.05 KB
figure3.png	38.63 KB
figure4.png	46.74 KB
figure5.png	68.87 KB
figure6.png	58.29 KB
figure7.png	77.2 KB
figure8.png	12.83 KB
figure9.png	20.8 KB
figure10.png	42.9 KB
figure11.png	81.43 KB