How to Do Username Token, X509 Certificates, HTTP Keystores, and STS Configuration
One of the features that I am very proud of in the HTTP Analyzer in
JDeveloper is the ability to test a SOAP service with the minimum of
fuss. Rather than having to configure security headers and understand
WS-Policy we make use of the WLS JAX-WS client to read and interpret the
policies defined in the WSDL and then apply abstracted credentials.
It turns out that this feature is very popular; but there is some confusion about just what information you might need to provide for a particular policy. So here is a simple summary of what is required for each type of policy.
The simplest pages just ask for a username and password. You are going to need this for policies that contains the phrase usernametoken, username, UNT or even HttpBasic and HttpDigest. The policy dictates where the values end up whether they be in an HTTP header or a WS-Security SOAP header.
The X509 panel is the most powerful and the most misunderstood. On this panel you can define a set of certificates and keys for both the client and the server.
The simplest version of this panel would be one that just contains the server key store. This is sufficient in most policy to be able to send a server an encrypted message and receive a message back. (In the most common case the server certificate is used to encrypt a symmetrical key, most likely AES, that can be used to decrypt the message being received.)
This will normally be enough unless the policy is defined as 2-Way HTTPS, most of the OWSM https policies I have worked with are 2-Way by default. The WLS ones tend to specify this explicitly. In the 2-Way case you again need to prove the identity of the client, and the only way of doing this is going to be with a Public/Private key that the server trusts.
On important feature to note is that when connecting to the STS store the analyser will be using values from the other three panels that we have discussed. This might be important if you are having trouble setting up a connection.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)