Mrudul's web blog

Check out new OpenSSO SDN article :

Enabling Web Service Security With OpenSSO WSS Agent

If answer is yes, then OpenSSO has a solution now, that works seamlessly on all containers supporting JAX-WS (which is the base for any Web Service)... including Glassfish, Tomcat, JBoss, WebLogic and WebSphere.

Download new Web Service Security Agents openssowssagents.zip, extract the zip and follow top level README file.
To try out included Web Service Client and Web Service Provider samples, follow samples/README file.

Check out OpenSSO STS related cool quick tips at OpenSSO wiki ... 

OpenSSO provides functionality of securing Web Services on various platforms.

This feature mainly includes :
1.Security Token Service
OpenSSO server is hosted as Trusted Authority being Security Token Service.

2.Web Services Security Agents
SOAP providers or plugins based on JSR 196 SPI and supported in Glassfish (Sun App Server 9.0 onwards) container. These plugins as the interceptors that secure and validate web services communication.

3.Client API
WS-Trust client API to get security tokens from OpenSSO hosted STS end point.
Client API to secure and validate web service request / response, using WS-Security tokens (SAML, X509, UserName, Kerberos, etc.)

OpenSSO uses Metro web services framework for WS-Trust and WS-Security (unified JSR 196) functionalities.

OpenSSO is built, shipped an deployed as single Web Application (.war file) and this web application is supported on all of the following containers :

1.Sun Java System Application Server 9.1 Update 1 and Update 2
2.Glassfish Application Server V2 UR1 and UR2
3.Sun Java System Web Server 7.0 Update 3
4.Apache Tomcat 5.5.x and 6.x
5.BEA WebLogic Server 9.2 MP2
6.BEA WebLogic Server 10.x
7.Oracle Application Server 10g
8.IBM WebSphere Application Server 6.1
9.Apache Geronimo Application Server 2.1.1
10.JBoss Application Server 4.x

Requirement :

OpenSSO web application when deployed as server (hosted STS end point) should be supported in all above mentioned 10 containers, with underline Metro web services framework for WS-Trust and WS-Security functionalities. Also for such support, we should not require any container specific settings / changes in either OpenSSO web application or in the container itself.

Problem :

OpenSSO uses underline metro jar files (webservices-api.jar, webservices-rt.jar, webservices-tools.jar, webservices-extra-api.jar, webservices-extra.jar, etc.) to build Web Services Security functionality on top. All these jar files are using latest 2.1 version of jaxb, jax-ws, saaj, etc. in OpenSSO web application (these jar files are bundled in the web app, under WEB-INF/lib). But OpenSSO web app has to run on all above 8 web containers which includes older versions (2.0) of jaxb, jax-ws, saaj, etc. jar files and keep them in container's global class path.
Hence there is a conflict.

Solution :

Implement OpenSSO specific Classloader logic to load web app's WEB-INF/lib jars (web services jar files of jaxb 2.1 version) in separate classloader (parallel to the container's classloader) and not conflict with web container's classpath and its classloader.

Theory :

STS entry or first invocation points from OpenSSO's web.xml bootstrap FAMClassLoader before invoking any Metro (web services relates) class files.

The first thing we check in FAMClassLoader is if Container classloader can load everything we need correctly, i.e. 2.1 classes. So we first check if it's loading JAXB API 2.1. This is done by trying to get resource (ClassLoader.getResource) of the class that is new in 2.1 version (new webservices-*.jar files). If this check detected that our environment (Container classloader) is already loading JAXB API 2.1 for us, then there's nothing else needed. We just proceed with the Container classloader to load all the classes.

But if this check detected that our environment is loading 2.0 API, then the real functionality of FAMClassLoader starts. First, we create a MaskingClassLoader that selectively disables (masks or hides) delegation of JAXB 2.1 API and everything that depends on it (like all the RI code) to the parent (Container) classloader.

/**    
* The list of package prefixes we want the    
* {@link MaskingClassLoader} to prevent the parent    
* classLoader from loading.    
*/   
public static String[] maskedPackages = new String[]{
"com.sun.istack.tools.",       
"com.sun.tools.jxc.",       
"com.sun.tools.xjc.",       
"com.sun.tools.ws.",       
"com.sun.codemodel.",       
"com.sun.relaxng.",       
"com.sun.xml.xsom.",       
"com.sun.xml.bind.",       
"com.sun.xml.bind.v2.",       
"com.sun.xml.messaging.",       
"com.sun.xml.ws.",       
"com.sun.xml.ws.addressing.",       
"com.sun.xml.ws.api.",       
"com.sun.xml.ws.api.addressing.",       
"com.sun.xml.ws.server.",       
"com.sun.xml.ws.transport.",       
"com.sun.xml.wss.",       
"com.sun.xml.security.",       
"com.sun.xml.xwss.",       
"javax.xml.bind.",       
"javax.xml.ws.",       
"javax.jws.",       
"javax.jws.soap.",       
"javax.xml.soap.",       
"com.sun.istack.",       
"com.sun.identity.wss.",       
"com.sun.identity.wssagents.",       
"com.sun.org.apache.xml.internal.",            
"com.sun.org.apache.xpath.internal.",       
"com.sun.org.apache.xalan.internal.",       
"com.sun.org.apache.xerces.internal.",       
"com.sun.identity.saml.xmlsig.",       
"com.sun.identity.xmlenc.",       
"com.sun.xml.stream."   
};


Then we create an URLClassLoader beneath it, by specifying the jar files of the JAXB 2.1 APIs. Now we have a classloader that can load JAXB API 2.1 and its RI without interference from the existing environment.

/**    
* The list of jar files to be loaded by FAMClassLoader.    
*/   
public static String[] jars = new String[]{       
"webservices-api.jar",       
"webservices-rt.jar",       
"webservices-tools.jar",       
"webservices-extra-api.jar",       
"webservices-extra.jar",       
"opensso.jar",       
"openssowssproviders.jar",       
"xalan.jar",       
"xercesImpl.jar",       
"openfedlib.jar"          
}; 

These are the simple steps to follow if you want to use your custom certificate for Web Services Security samples (from openssoproviders.zip) :

Note : Out of box, OpenSSO uses "test" certificate and its alias in bundled keystore.jks. The keystore or certificate store password and key password is "changeit".

1) Create custom certificate and custom keystore.jks using "keytool"
keytool -genkey -keyalg rsa -alias custom_cert_alias -dname "CN=custom.sso.apps.testbed, OU=Custom_org, O=Custom_company, L=Custom_city, ST=Custom_state, C=Custom_country" -keypass changeit -keystore keystore_custom.jks -storepass changeit
This creates keystore_custom.jks with "custom_cert_alias" certificate.

2) Replace server keystore
cd <opensso config dir>/<opensso_deploy_uri>
cp keystore_custom.jks keystore.jks

3) Replace client keystore
wherever you have unzipped openssoprovider.zip
.../resources/
cp keystore_custom.jks keystore.jks

4) Changed key alias from "test" to "custom_cert_alias" in Server -> Configuration -> Sites and Servers -> Default server configuration

5) Changed key alias from "test" to "custom_cert_alias" in Client <GF install dir>/addons/opensso/AMConfig.properties
Make sure keystore location is pointing to (3)

6) Changed key alias from "test" to "custom_cert_alias" in wsc, StockService (if you have this one), wsp agent profiles

Restart the GF container and you can exercise StockQuoteClient sample successfully with X509 token and signing on. Also verify that it is using custom certificate.

WS-* technologies were everywhere in Burton group's Catalyst conference (Barcelona 22-25 October, 2007) and in IOP event, along with InfoCard selectors... with focus on WS-Trust, WS-SecurityPolicy, WS-Security, WS-I BSP Security tokens, etc.

The SUN's OpenSSO IDP/STS presentation and IOP results talk about more...

 

Presented 'Java EE Security using Access / Federation Manager' at UC Davis 2007 IT Security Symposium.

Hands-On Lab went live on the Identity Management home page :
http://developers.sun.com/identity/

Hands-On Lab: Securing Identity Web Services (LAB-5410)
<http://developers.sun.com/learning/javaoneonline/j1lab.jsp?lab=LAB-5410&yr=2007&track=8>

This lab shows how to use OpenSSO (Sun Java System Access Manager) deployed within the
Java Application Platform SDK to configure authentication source and identity repositories.
It demonstrates how Web services can be secured using standard security mechanisms.
(SDN registration (free) required.)

Java Application Platform SDK Update 3 Preview/Java EE 5 SDK Update 3 Preview/Java EE 5 Tools Bundle Update 3 Preview/GlassFish contest, etc. are now live.

Home page: http://java.sun.com/javaee/
New download "early access" page: http://java.sun.com/javaee/downloads/ea/

Try it out ...

 

Web Services are everywhere ....

JavaOne 2007 complete session schedule is now available.

Session#	Title
TS 4865	Takes two to Tango: Java Web Services and .NET Interoperability
TS 4948	Unleashing the Power of JAX-WS RI: Spring, Stateful Web Services, SMTP, and More
TS 6411	JSR 311: The Java API for RESTful Web Services
TS 8840	Services Interoperability with Java Technology and .NET: Technologies and Tools for Web 2.0
BOF 6412	Describing RESTful Applications: WADLing with Java

tutorial on securing communications in Web services is on SDN now.

This uses and is provided via Sun Java System Access Manager, the Java Application Platform Software Development Kit (SDK) with Tools bundle (including NetBeans EP 5.5).

Try Access Manager 7.1 (as a single war) and its Web services security functionality (using both, WS-I BSP as well as Liberty tokens) via Application server container plugin (Web services security agent), when you install any of the following -

1. Java Application Platform SDK Update 2 - Download / Download with JDK / Download with Tools (from http://java.sun.com/javaee/downloads)
2. Java EE 5 SDK Update 2 - Download with Tools (from http://java.sun.com/javaee/downloads)
3. NetBeans Enterprise Pack 5.5 (from http://www.netbeans.org)