Wednesday Apr 11, 2007

XWSS adoption in the industry

It's always exciting to see XML and Web services security (also shipped in glassfish now) more widely used in the industry. Here's another success story of XWSS adoption.

Another highlight?

Glassfish goes to Harvard!

Monday Apr 02, 2007

Monitoring secure SOAP Messages

If you're working on a security scenario on glassfish, have been looking at signature validation failing the Nth time... and are ready to pull your hair out (whatever's left), it's time to sit back, take a deep breath and do some deeper thinking.

Security is not your enemy, its your friend, its just that you need to learn to communicate! The language you can start babbling is that of (FINE grained) logging and HTTP dumping.

One way to do this is to open the file /domains/domain1/config/domain.xml and add the following lines to the jvm-options section:


<jvm-options>
-Dcom.sun.xml.ws.transport.http.HttpAdapter.dump=true
</jvm-options>

<jvm-options>
-Dcom.sun.xml.ws.transport.http.client.HttpTransportPipe.dump=true
</jvm-options>

And then start the server. Well, a better and smarter alternative to the above (in my opinion) is to use the Glassfish admin tool to do the same thing and then ofcourse restart the server for the settings to take effect.

Trivia: Did you know you could use the admin tool to change glassfish's jvm-option settings?

The other thing you want to do is to configure fine grained logging for the security packages. Here's what I am talking about.

In his blog, Fabian talks about configuring logging in GlassFish 9.1 for the WS-Policy implementation.
Only, instead you now enter com.sun.xml.ws.security.trust for trust, com.sun.xml.ws.security.secconv for secure conversation, com.sun.xml.wss.impl for xwss, and set the value FINE (or any other logging level that suits you) to any or all of these.

Thanks for reading. I hope this helped...

Friday Mar 30, 2007

Testing a secure webservice using JUnit

While working on creating a glassfish-sample for XML and Web Services Security(XWSS). Having everyone so often say "It's always nice to have unit tests", "developers should unit test their applications", its good practice, I thought I might as well write a JUnit test.

Now if I am just writing a secure client, I know I have to have wsit-client.xml that contains the security policy information and this is packaged and picked up correctly from the client webapp.

But using plain old JUnit, I do not have a webapp, and so the big question is "How do I test my secure web service using a standalone JUnit java class?". Good question, I thought.

In the absense of a wsit-client.xml, how is the client to know how and what to secure in the request it sends the service?. Quite understandably (and annoyingly so), the service keeps complaining "No security Header found". It's just saying it got a request that just wasn't secure.

So what is the solution? I already have a client webapp that is sending a secure request and the way I run the client is by invoking the client webapp from my browser. Isn't it?

Now if only there was a way to do this through JUnit....

There exists a framework called htmlunit that does this.

I read up the getting started on htmlunit page and created my JUnit test that invoked the secure service!! Here is what it looked like-


package webservices.secure_bank_app_client;

import java.net.URL;

import com.gargoylesoftware.htmlunit.WebClient;
import com.gargoylesoftware.htmlunit.html.HtmlAnchor;
import com.gargoylesoftware.htmlunit.html.HtmlElement;
import com.gargoylesoftware.htmlunit.html.HtmlInput;
import com.gargoylesoftware.htmlunit.html.HtmlPage;
import com.gargoylesoftware.htmlunit.BrowserVersion;

import junit.framework.TestCase;
import junit.framework.Assert;

/\*\*
 \* This test class tests secure bank application.
 \*/
public class SecureBankTest extends TestCase {
    
    // System property values used to configure the HTTP connection
    private String contextPath = "/secure-bank-app-client";    

    private String host = null;
    private int port = 0;
        
    /\*\* Set up instance variables required by this test case. \*/
    public void setUp() throws Exception {
        
        host = System.getProperty("javaee.server.name");
        port = Integer.parseInt(System.getProperty("javaee.server.port"));
             
    }
    
    public void testHomePage() throws Exception {
       
        final WebClient webClient = new WebClient(BrowserVersion.MOZILLA_1_0);
                
        final HtmlPage page = (HtmlPage)webClient.getPage(getURL("/"));
        
        Assert.assertEquals( "Secure Bank Order Page", page.getTitleText() );
    }
    
       
    private URL getURL(String path) throws Exception {
               
        StringBuffer sb = new StringBuffer("http://");
        sb.append(host);
        if (port != 80) {
            sb.append(":");
            sb.append("").append(port);
        }
        sb.append(contextPath);
        sb.append(path);
        return (new URL(sb.toString()));

    }

    
}

Another problem solved.. for today atleast. Do you run into similar problems too? Would like to share how you solved them?

Thursday Mar 29, 2007

XWSS on Maven

For all Maven fans out there, who didn't know this -- XML and Web Services Security(XWSS), versions 2.0 and 3.0 bits are also in the maven repository .

Try these out and let us know if you have any feedback. Or just post a comment here. :)

On configuring Glassfish keystores...

Ok, so you like glassfish . You really think that message based security is pretty cool. You've even tried the security samples (successfully!). Now you're ready to take the next big step. Try creating your own secure application and attempting interoperability. Except that there is one problem.

You don't have the certificates and keys you need to interoperate in the glassfish keystore and truststores! You're thinking what do I do now? Well, just read on....

Let's see what we know. For an application to interoperate, you need to know the keys to be used for encryption and digital signing. The certificates and keys to be used are typically negotiated out of band between both parties. So you should have the certificates with you. If you have them in a JKS format, here's what you can do to configure your keystore.

In a snapshot, what you need to do is get the copyv3 module, modify the ant script so that you import the correct keys into the default glassfish keystore and truststore.

Let's say your client alias is alice and server alias is bob. The client trusts bob and server trusts alice.

Here's roughly how the updated script looks like-

<project name="keycopy" default="main" basedir="."> 
	<property environment="env" /> 
	<property name="proxy.host" value="webcache.sfbay.sun.com" /> 
	<property name="proxy.port" value="8080" /> 
	<property name="AS_HOME" value="${env.GF_HOME}" /> 
	<target name="main" description="copy v3 keypair to GF Keystore"> 
	<setproxy proxyhost="${proxy.host}" proxyport="${proxy.port}" /> 
	<java classname="KeyImport" dir="." fork="true"> 
		<arg value="srcstore=server-keystore.jks" /> 
		<arg value="dststore=${AS_HOME}/domains/domain1/config/keystore.jks" /> 
		<arg value="srcalias=bob" /> 
		<arg value="dstalias=bob" /> 
 		<classpath> 
			<pathelement location="./test.jar" /> 
		</classpath> 
	</java> 
 	<java classname="KeyImport" dir="." fork="true"> 
		<arg value="srcstore=client-keystore.jks" /> 
		<arg value="dststore=${AS_HOME}/domains/domain1/config/keystore.jks" /> 
		<arg value="srcalias=alice" /> 
		<arg value="dstalias=alice" /> 
 		<classpath> 
			<pathelement location="./test.jar" /> 
		</classpath> 
	</java> 
 	<java classname="KeyImport" dir="." fork="true"> 
		<arg value="srcstore=server-truststore.jks" /> 
		<arg value="dststore=${AS_HOME}/domains/domain1/config/cacerts.jks" /> 
		<arg value="srcalias=alice" /> 
		<arg value="dstalias=alice" /> 
		<arg value="trustedentry=true" />  
		<classpath> 
			<pathelement location="./test.jar" /> 
		</classpath> 
	</java> 
 	<java classname="KeyImport" dir="." fork="true"> 
		<arg value="srcstore=server-truststore.jks" /> 
		<arg value="dststore=${AS_HOME}/domains/domain1/config/cacerts.jks" /> 
		<arg value="srcalias=xws-security-client" /> 
		<arg value="dstalias=xws-security-client" /> 
		<arg value="trustedentry=true" /> 
		<classpath> 
			<pathelement location="./test.jar" /> 
		</classpath> 
	</java> 
	<java classname="KeyImport" dir="." fork="true"> 
		<arg value="srcstore=client-truststore.jks" /> 
		<arg value="dststore=${AS_HOME}/domains/domain1/config/cacerts.jks" /> 
		<arg value="srcalias=bob" /> 
		<arg value="dstalias=bob" /> 
		<arg value="trustedentry=true" /> 
		 <classpath> 
			<pathelement location="./test.jar" /> 
		</classpath> 
	</java> 
</target> 
</project>

Get set (glassfish home), on your mark (edit aliases, source JKS keystore names), go (run the script)!

Now you are all set to test out your secure application! Security can be a tricky thing. Let me know if you thought this was confusing....and do share your ideas if you think this could be made any simpler!

About

manveen

Search

Archives
« July 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
  
       
Today