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.
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.
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.
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.
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
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.
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:
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;
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