If you have a WebService configured to use the Mutual Certificates Security  mechanism as supported by Netbeans.  Then when developing a client for the service you would generally be required to configure the client side keystore alias or provide a callbackhandler. And since it is a mutual certificate scenario you would also have to configure an alias from the truststore or a callbackhandler to identify the server certificate on the client side.  Sometimes it may not be practical to expect the  Certificates to be present inside a  Java Keystore.   The application invoking the WebService Proxy might obtain it from other sources (not necessarily a Java Keystore).  With the latest metro builds starting 25th November  you should be able to set the information as follows :

import com.sun.xml.wss.XWSSConstants; .... try { // Call Web Service Operation test.MyWebService port = service.getMyWebServicePort(); java.lang.String parameter = " This is a Secure Test"; //You may have them available from various sources (including from some URL) //For the purpose of this sample i would read them from files. CertificateFactory fact = CertificateFactory.getInstance("X509"); X509Certificate cert = (X509Certificate) fact.generateCertificate(new FileInputStream("D:\\openesb\\client-cert.der")); PrivateKey key = readPrivateKey("D:\\openesb\\client-key.der"); X509Certificate serverCert = (X509Certificate) fact.generateCertificate(new FileInputStream("D:\\openesb\\server-cert.der")); ((BindingProvider) port).getRequestContext().put(XWSSConstants.CERTIFICATE_PROPERTY, cert); ((BindingProvider) port).getRequestContext().put(XWSSConstants.PRIVATEKEY_PROPERTY, key); ((BindingProvider) port).getRequestContext().put(XWSSConstants.SERVER_CERTIFICATE_PROPERTY, serverCert);                 java.lang.String result = port.operation(parameter); out.println("Result = " + result); } catch (Exception ex) { // TODO handle custom exceptions here }

As you can see i am reading the certificates and private-key from DER encoded files.  Here is the non-trivial readPrivateKey() method that is used above :

/**  * Private key should be in "DER" format.  */ public static PrivateKey readPrivateKey(String fileLocation) throws Exception { FileInputStream fis = new FileInputStream(fileLocation); byte input[] = new byte[fis.available()]; fis.read(input, 0, input.length); PKCS8EncodedKeySpec spec = new PKCS8EncodedKeySpec(input); KeyFactory key_fac = KeyFactory.getInstance("RSA"); return key_fac.generatePrivate(spec); }

          
So as you can see we have introduced three properties CERTIFICATE_PROPERTY, PRIVATEKEY_PROPERTY and  SERVER_CERTIFICATE_PROPERTY.  These properties are akin to BindingProvider.USERNAME_PROPERTY and BindingProvider.PASSWORD_PROPERTY supported in JAXWS specification for Basic Authentication.  They serve to supply the  Client Certificate,  Client PrivateKey and Server Certifcate respectively.  Note that for programmatically specifying username and password for secure Metro scenarios that involve username, we already advocate the use of  XWSSConstants.USERNAME_PROPERTY and  XWSSConstants.PASSWORD_PROPERTY.

The metro client side configuration file wsit-client.xml does not need to have any Keystore/Truststore configuration in this case. Infact there is no need for a wsit-client.xml (client side configuration) in this case and if you are using NetBeans it will not generate one unless you try to specify any of the Keystore information.

Now you can also get rid of the wsit-client.xml for the first NetBeans secure mechanims "Username Authentication with Symmetric Keys" by specifying the following three properties. 

1.  USERNAME_PROPERTY
2.  PASSWORD_PROPERTY
3. SERVER_CERTIFICATE_PROPERTY

try { // Call Web Service Operation test.MyWebService port = service.getMyWebServicePort(); java.lang.String parameter = " This is a Secure Test";                 CertificateFactory fact = CertificateFactory.getInstance("X509"); X509Certificate serverCert = (X509Certificate) fact.generateCertificate(new FileInputStream("D:\\openesb\\server-cert.der")); ((BindingProvider) port).getRequestContext().put(XWSSConstants.USERNAME_PROPERTY, "test"); ((BindingProvider) port).getRequestContext().put(XWSSConstants.PASSWORD_PROPERTY, "test"); ((BindingProvider) port).getRequestContext().put(XWSSConstants.SERVER_CERTIFICATE_PROPERTY, serverCert);                 java.lang.String result = port.operation(parameter); out.println("Result = " + result); } catch (Exception ex) { // TODO handle custom exceptions here }

The  SERVER_CERTIFICATE_PROPERTY is required when using this mechanism because it is used to secure (encrypt) a Random SecretKey which is then used to Sign and Encrypt the Request Message from the Client. 

With all the complexity of WS-* specifications sometimes we get a feeling that it has become a little hard to do some very simple secure scenarios.  For example someone just wants to send a simple username and password (no signature or encryption). Someone just wants to sign the message payload, or just encrypt the message payload.  Unfortunately you have to hand edit the  WS-SecurityPolicy assertions in the WSDL (OR Metro wsit-*.xml, configuration file) today.  Nebeans defines a predefined set of  Security Mechanisms which we believe would cover the most common usecases. But we have always found people wanting to do other things.  One approach is to pick the closest Netbeans Mechanism and generate the initial  Metro configuration file and then manipulate the  Policy assertions to suite your needs.  In the coming weeks i will try to post  how one can do some of the very simple Username/Password, Password Digest, Sign-Only etc. scenarios with Metro. I shall post the policies of the service for your use.   I might use the  properties described in this blog for simplicity in configuring the client.