Technical background  By ngoc.giang.nguyen and W.ZH

This section reviews some related technologies.


SOAP is the protocol that specifies how a exchanged message between client and web service should be formed. Currently, there are 2 versions of SOAP being used: SOAP 1.1 and SOAP 1.2. The differences between SOAP 1.1 and SOAP 1.2 are usually irrelevant to end-users. For further information, please refer to this article.
When exposing a function, the web service always specifies which SOAP version the client should use to form the invocation message. It is done by supplying the appropriate namespace to the binding tag. E.g, for SOAP 1.2, the namespace should be; while for SOAP 1.1, the namespace should be The message sent by the client to a web service function must be of the same SOAP version with that function.
SOAP 1.2 is supported by most of the application servers such as OC4J and WebLogic?.


JAX-RPC is the protocol that specifies how to invoke a web service function. It can be seen as the bridge between WSDL, the guy who talks in business terms, and the application server, the guys who talks in technical terms. Using JAX-RPC tool, from a WSDL, we can generate a set of Java code understood by the application server.
JAX-RPC is good in communication, but it attempts to do extra thing, i.e. generating the mapping from WSDL data types to Java, and does it very badly. Not all types defined in WSDL are generated. The generation is done in a best-effort basis. When a type cannot be generated, a generic type (SOAPElement) is used instead. As a result, generated code is often unusable, or users have to do manual mapping on unsupported data types. In short, JAX-RPC mapping technology is an evolutionary dead-end, and soon people will move away from it.
JAX-RPC is the current web service standard and is fully supported by most applications servers such as OC4J and WebLogic?.


JAXB is the XML mapping framework. The beauty of JAXB is that it bases on XML schema instead of predefined type as in JAX-RPC. Given an arbitrary XML schema, JAXB can generate corresponding Java code. At runtime, an XML string can be parsed again the schema to obtain Java object, and vice versa.
JAXB is a standalone technology and is not necessarily affiliated with web service.
There are 2 available versions of JAXB: JAXB 1.0 and JAXB 2.0. Oracle XDK 10g supports JAXB 1.0 only, while WebLogic? supports JAXB 2.0.

==================== JAXB in Jdev 11g ==============================


JAX-WS is the marriage of JAX-RPC communication (which is the good part of JAX-RPC) and JAXB data binding. Therefore, it is much more superior than JAX-RPC and become standard in Jdeveloper 11g.
JAX-WS is only supported in Weblogic 10 and Oracle 11g onwards.

How to start the Web Service Security in SOA

By W.ZH, June 30 2011In the last one month, I gave some time to the Web Service Security on SOA Suite. My feeling is that this field might be one of the most challenge part in the whole SOA suite, As other part of the SOA features in fact are relatively easy to pick up and easy to test by the code sample that the developer guide giving. And you also can find many samples in the web, such as Event and Rules and also Process. But for WS Security, it is not easy to find some good examples in web and you need to read several guide in SOA and Weblogic to see its full picture.

First, you need to read some basic doc about the WS security, Such as  industry standard, WS Security and Policy

Of course,  suppose you have already know the security knowledge, such as key, encryption, certification, signature etc. (Luckily I am CISSP.)

There are also a series articles from
Bilal Siddiqui worth to read, to know the general knowledge.

Next step, I think good start is from the Web Service and Security part of the Weblogic Server, because SOA WS security in fact total rely on WLS.

  • Introducing WebLogic Web Services for Oracle WebLogic Server 11g
  • Getting Started With JAX-WS Web Services for Oracle WebLogic Server 11g
  • Securing WebLogic Web Services for Oracle WebLogic Server 11g
  • WebLogic Web Services Reference for Oracle WebLogic Server 11g
  • Security and Administrator’s Guide for Web Services 11g
  • Understanding Security for Oracle WebLogic Server 11g

Based on this, you can start do some testing in WSL, such as to apply a security policy  to a WS , and then to see how to access it, Then simple one might be

oracle/wss_username_token_client_policy (or http one). Because of it can be tested from Web UI of the middleware control very easily, You just need to  input WSS user name and password to test your WS to see this policy works or not, and next step you can develop a java client to access your service.

Use a sniffer to check the SOAP XML , You will find something like this in SOAP Header:

<wsse:Password Type=””>password</wsse:Password&gt;

You need to know how to create a WS proxy code from Jdeveloper Wizard and then to use this client to test a normal WS, then You can try to change code to access that WS protected by the oracle/wss_username_token_client_policy , read “A.6 Adding Oracle WSM WS-Security Policies to Clients”

and also to set the user name and password into the SOAP header, something like this for JAX-WS:

BindingProvider bindingProvider = (BindingProvider) port;
Map<String, Object> reqContext = bindingProvider.getRequestContext();
reqContext.put(BindingProvider.USERNAME_PROPERTY, “testaccount“);
reqContext.put(BindingProvider.PASSWORD_PROPERTY, “xxxxxx”);

You can get some forum answer about this part, and you can do more search about this, although very few in fact.

Then you should be able to make your client can access the secured WS, which is blocked by the wss_username_token_client_policy.

Of coz you see that user name and password are clear text in SOAP header, next step is you need to set the security provider and use user account X509 certification, token etc to replace the user password. After get here you already to know the basis of the WS sec in WLS, you can do more testing for other policies and to see how to access from client.

If existing policies WLS has, does not meet your request, then how?

You need to read “13 Creating Custom Assertions” in Oracle® Fusion Middleware Security and Administrator’s Guide for Web Services.

I know there is errata about this chapter in some doc, do a search if you use wrong version. Custom Assertions can be used to create a new Custom Policy and apply to your Web Service as one of the existing policy, work together with wss_username_token_client_policy and others. (As them are chained), In your Assertion code you can get the user Identity and do any check you want for your WS. I have done this part and prove this concept working well!

About further goes into the SOA Suite WS Security, I will start another article about my findings.

Note: every time you re-depoly your web service, all the sec policy attached to your WS will get removed, you need to re-attach them. (As your WSDL might change?)

Some links might useful:

SOAP Msg coding