Posts Tagged soap
Sometimes, you encounter old WSDL service definitions, based on RPC style SOAP instead of the newer Document based litteral encoding.
To discover wether a WSDL is using RPC or literal encoding, check the “style” parameter of the “binding” element, such as
<binding name="A_WebServiceBinding" type="tns:A_WebServiceRPC">
<soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="rpc"/>
In Java, RPC based SOAP is implemented by JAX-RPC, a quite old API developed for Java 1.4. As it is older than JAXB, it even implements its own XML to Java object mapping.
When SOAP 1.2 was released, the Java platform switched to the newer JAX-WS implementation to support it along with other stuffs, namely HTTP Binding (aka XML over HTTP without SOAP), a new data mapping model and support for WS-I basic profile 1.1
You can read this IBM article for a very good, while concise, description of JAX WS vs JAX RPC.
In NetBeans 7.0, only JAX WS is provided out of the box. When you encounter older WSDL, based on RPC encoding, you must manually install JAX-RPC. However this plugin is not provided in the default plugin repository anymore. You will need to add another plugin repository :
- Select “Tools” in the menu, then “Plugins”, then the “Settings” tab.
- Add a Repository with the name you choose and this URL : http://deadlock.netbeans.org/hudson/job/nbms-and-javadoc/lastStableBuild/artifact/nbbuild/nbms/updates.xml.gz
- Then go back to “Available Plugins” and type RPC in the search box, you should find JAX-RPC in the list of proposed plugins.
- Follow the instructions to download and install the plugins.
Et voilà, you are now ready to create JAX RPC based Java clients by choosing the “File” menu, then “New File” then choose “Web Service Clients” in the “Web Services” section.
An Open Source implementation is also available from ForeRock’s OpenAM.
To summarize, a Secure Token Service is a third-party broker where Web Services clients can authenticate and receive a security token to be sent to a Web Service Provider. The Web Service Provider will, in turn, validate the token and to evaluate authentication and authorization decisions.
There are three approaches to interact with STS Server
Approach #1 – STS’s WSDL definition
This is the platform agnostic approach. Just rely on STS’s WSDL definition to generate whatever client code you will need.
Unfortunately, on Java SE 6, this approach fails because of incompatibilities in OpenSSO’s STS WSDL definition and JAX-WS.
Stay tuned on ForgeRock’s JIRA for more details on this approach.
Approach #2 : Using JAX-RPC and JSR 196 provider
JSR 196 is a SPI specification allowing to hook a filter inside a container. This filter will be invoked for all incoming and outgoing JAX RPC call, allowing it to be used for logging or security purposes for example.
OpenSSO and OpenAM do provide a JSR 196 provider for web service authentication (JSR 196) and authorization (JSR 115). This provider is able to work with an STS provider. The provider is available as part of openssowssprovider.jar JAR file.
However, this approach has a major drawback : it is JAX RPC based, i.e. quite old, now that the (Java) world has embraced JAX WS. In other words, Oracle only supports this when the web service provider and the web service consumer are deployed into a GlassFish v2 instance.
So, if you want to use JAX WS, you will require a little more work.
Approach #3 – JAX WS
JAX-WS also provides hooks to intercept outgoing and incoming SOAP requests. These hooks are named “Handler“.
The good news about Handlers is that they are web-app specific, unlike JAX-RPC JSR 196 provider which are installed at container level; hence for all your web applications.
You can think of an Handler as a Servlet Filter, dedicated to web service calls. They can be part of a web app, to protect web services providers, or stand alone client, to protect web service consumers. IBM has a very good documentation about using Handlers with JAX WS web services.
To test OpenSSO / OpenAM STS service with JAX WS handlers, I suggest you to read this tutorial.
Unfortunately, you will soon realize that these step by step instructions are not working.
Problem #1 : Oracle removed the download link to openssowssagents.jar file. Yes you read it right. As of today, there is no binary distribution for the JAX WS Handlers and WSS Agents. The JAR file is only available from ForgeRock.
Problem #2 : JAX-WS ClientHandler and ServerHandler are not included in openssowssagents.jar file. So even, if you are downloading ForgeRock’s JAR file, you won’t get these two JAX WS handlers.
So the only solution is to download the source code and built it yourselves. Building OpenSSO / OpenAM is not an easy task. This product has many dependencies and historical (legacy) branches. Anyway, your build will not be supported by Oracle nor ForgeRock. For your convenience, here is a openssowssagents.jar file with the JAX WS classes included.
Should you have a valid support contract with Oracle and/or ForgeRock, do not hesitate to open a support case and see what / if /how they will handle this situation.
When selling GlassFish ESB to partners, we (Sun) have to provide our partners with all the material allowing them a quick ramp-up on our technology. That’s the main reason why my group (Sales Engineers, Northern Europe) created a 3 days GlassFish ESB technical workshop.
My contribution to this workshop is a one hour module about WS-Security and GlassFish ESB (and OpenESB). The idea is to demonstrate how easy it is to setup a WS-Security enabled channel between a web service provider and a web service client.
Specifically, the screencast tutorial shows how to establish mutual certificate authentication between an EJB based web service and a JBI service assembly, acting as web service client, in this case, a BPEL module.
To learn more about WS-Security, I recommend this reading.