OpenSSO and Secure Ticket Service (STS)

The setup involves a Liferay Portal that authenticates the users using OpenSSO Express 8. The portlets make SOAP calls to a JBoss 5.1 server that has some EJB’s exposed as a web service provider.
The principle behind STS is really simple. You don’t have to change your webservice provider, client or WSDL. Just plug the right client and server handler, configure OpenSSO and go!
On the SUN Development Blog there is an excellent walk through named Enabling Web Service Security with OpenSSO WSS Agent. This post is about our experience with this setup and the pitfalls we encountered.

Getting – Thank you Oracle

OpenSSO integrates the STS client and provider using JAX-WS client- and server-handlers. These are contained in, which was provided at
Oracle removed most of the downloads from the OpenSSO site after completing the SUN merger. Fortunately a new company called ForgeRock took the OpenSSO source code and will continue its development of under the OpenAM name. They provide downloads and source code for OpenAM Express 9. Currently a nightly build of is provided; however a stable OpenAM Express 9 build isn’t.
I decided to build OpenAM Express 9 on my one.
Big mistake; it took me more than half a day. First of all you need to download and compile a lot of dependencies. Next steps involved building the components using several ant scripts and commands. Since no real documentation exists, this was a trial and error effort. I sure hope the build gets mavenized soon!
But let me save you this little inconvenience: OpenSSO Express 9

@ClientHandler and Tomcat

Configuring OpenSSO and the JBoss Webservice Provider worked like a charm, but we couldn’t get the ClientHandler to work. We tried both using ws-import and adding @ClientHandler to the client ourselves.
Since Tomcat is not a full JEE container, it doesn’t support JSR 109 service endpoints and thus no fancy @ClientHandler annotations. We solved this by adding the client handler in our factory class:
public ServiceFactory(String wsdlLocation) {
service = new ServiceImpl(wsdlUrl, new QName(TARGET_NAMESPACE, LOCAL_PART_SERVICE_IMPL));
service.setHandlerResolver(new STSHandlerResolver());

private class STSHandlerResolver implements HandlerResolver {
public List getHandlerChain(PortInfo portInfo) {
List handlerChain = new ArrayList();
handlerChain.add(new com.sun.identity.wssagents.jaxws.client.ClientHandler());
return handlerChain;


Our OpenSSO setup uses url-encoding for the iPlanetDirectoryPro cookie. Without it, tomcat will give up on the = character. The openssoclientsdk doesn’t like this. It only supports unencoded cookies or c66encoded cookies. c66 encoding is an OpenSSO specific url encoding. The cookie contains the site the web service client has to connect to get the STS Ticket. If the cookie can’t be decoded, the connection url will be empty.
You’ll have to enable the property in the OpenSSO console to fix this.

SOAP 1.2

Next up: what SOAP are you using? The STS Client Handler only supports SOAP 1.2, but the JAX-WS default is SOAP 1.1.
Generating a WSDL for 1.2 isn;t that hard though, unless you’re using JBoss & Metro. Due to a bug JBoss won’t generate SOAP 1.2 WSDL’s. We used the wsgen goal of the jaxws-maven-plugin to generate SOAP 1.2 and make sure to set extension=true on to create the correct WSDL while building the provider.
At the client side the wsimport goal should generate the right code, but only with extension=true
Now you should have a working SOAP 1.2 – STS setup, unless…

Sync you clocks

When generating a STS Ticket, OpenSSO will check the clock difference between the STS web service client and the OpenSSO instance. A maximum of 5 seconds is allowed. If the difference is bigger and you cannot change (one of) the clocks, you can adjust it by setting the property in the OpenSSO console to something bigger (3600000 in our case). This isn’t recommended for production environments of course…

More Here