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 WSSAgents.zip – Thank you Oracle
OpenSSO integrates the STS client and provider using JAX-WS client- and server-handlers. These are contained in WSSAgents.zip, which was provided at http://opensso.dev.java.netOracle 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 WSSAgents.zip 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 WSSAgents.zip
@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;
}
}Encoding
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 com.iplanet.am.cookie.c66encode 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 com.sun.identity.wss.security.timeskew property in the OpenSSO console to something bigger (3600000 in our case). This isn’t recommended for production environments of course…More Here
Courtesy:http://blog.iprofs.nl/2010/04/29/opensso-and-secure-ticket-service-sts/