Tuesday, August 28, 2012

Visualizing Code in Eclipse (Using Architexa)

I am here sharing a nice tool I recently found to draw the diagrams for my final year project at university. When the project is concerned, managing it is challenging with, 
  • code base of the project is pretty large
  • a team is working on the project
  • we need to maintain the quality and performance of the project 
  • proper documentation is also evaluated
So we were searching for an easy to use and nice looking tool to achieve the purposes without making it annoying that, we can focus more on the logic and optimization than decorating a diagram. :) That is were I found this plugin for eclipse called Architexa client, which is free for use.

Following is a sequence diagram I generated using the plugin, which didn't take more than 30s to draw than dragging the relevant classes and setting the relevant calls.

Following is a class diagram generated, that you can clearly observe the clear and smart look of the diagrams.


  1. From several tools that I have tried this was more faster and the diagram quality is great.
  2. It provides you the flexibility on deciding how the diagrams needs to be drawn, but to the rest on it's own.
  3. It provides sharing options with the tool that I am eager to try out.
  4. There several options to save and share the diagrams as images or files inside the project.
Rather than calling this cons, it is more suitable that I call them possible improvements that I haven't even seen them with any other freely available tool I tried.
  • This is little inconvenient to see generated members are not set in an orderly manner that always have to manually place them in order, as in following diagram.
Finally drawing diagrams has become fun, up-to date, truly useful and effective for code development for me. You can checkout whether it fits for you from here
I will share more experience with Architexa as I get more familiar. Cheers!

Monday, August 20, 2012

Generating Key Pairs and Importing Public Key Certificates to a Trusted Keystore

Through this I am sharing the most simple scenario to follow in using Java keytool for the requirements of Apache Wookie projects digital signature implementation. Anyway if you are looking to know how to generate a key pair or import a certificate to a Keystore using keytool, still this may be helpful. Refer this segment of Java SE documentation to know in-depth details.

You needs a configuration of Java in your computer to use keytool and that is enough :).

Generating Key Pairs

Use following command in command prompt to generate a keypair with a self-signed certificate
keytool -genkey -alias wookie -keyalg RSA -keystore wookieKeystore.jks -keysize 4096
After  -alias give the alias to be used for keys
          -keylag give the algorithm to be used in key generation
         -keystore give the name of the keystore with type .jks (You can give a path here to store the keystore in a desired place)
          -keysize give the length for the generating key in bits
This will look something as follows,

That's all and you are having a key pair now. :) 
In Aspects of Wookie, now you can sign Widgets using this keystore. But in order to get your widgets verified and deployed in Wookie server you needs to get your public key trusted by server directly or via a third party.

Generating .cer File

To insert a public key certificate into a trusted keystore it needs to be exported as a .cer file. (There are several other options to use too.)
keytool -v -export -file keystore1.cer -keystore wookieKeystore.jks -alias wookie

Importing Public Key Certificates to a Trusted Keystore

To import a trusted certificate to a trusted keystore following command can be used.
keytool -import -alias keystore1 -file keystore1.cer -keystore wookieKeystore.jks
This command simply says to import the public key certificate of key having alias 'keystore1' which is in the file keystore1.cer to the keystore 'wookieKeystore.jks'.

Now any signature generated using the private key of keystore1 aliased key pair, can be properly validated using wookieKeystore.jks.

Sunday, August 19, 2012

Apache Wookie W3C Widget Digital Signature Implementation - GSoC2012

I am here sharing my GSoC 2012 project details which I enjoyed a lot while learning. This includes a brief introduction on the project with it's design, implementation and guidance on using. The implementation has been done using Apache Santuario 1.5.2 release to generate digital signatures. The project is mentored by Scott Wilson who was so helpful and supported by the community. This is Scott Wilson's post on the project.

What is Apache Wookie?

Apache Wookie is a Java server application that allows widget uploading and deployment as useful for variety of applications. This may include gadgets to quizzes and games. Wookie has been based on W3C widget specification while providing flexibility on Google Wave gadgets etc. At the moment of writing, it is in the Apache incubator getting ready to graduate as an Apache Project. 

Objective of the project

The objective this project is to implement the 'W3C XML Digital Signatures for Widgets' specification in Wookie which has been reported as a new feature. This means automating the widget upload and deployment in a secured manner without  having an administrator to approve each widget. If a widget store or an author is trying to deploy a widget, Wookie needs to be capable of ensuring whether it's a trusted party and let deployment or avoid it as suitable.


The best way to achieve this is letting the widgets' content be digitally signed and verifying the signatures at Wookie before deployment. In the way basic security needs of integrity and non-repudiation can be achieved according to W3C XML digital signature for widgets specification. So a new module has been introduced to Wookie as digsig-client to allow authors and distributors to sign the content of widgets. It provides a user friendly Java Swing UI to get the inputs from the signer. Then process them according to the W3C spec and package into a .wgt ready to be deployed in Wookie server. The client is developed according to Model View pattern separating the signing logic and UI having a coordinator among them.

Then the administrators are allowed to set up the security level of the server whether to reject the widgets that do not submit a valid signatures or to allow them under a warning. 



The signature is generated according to the exact details specified in the spec as,
  • Signature algorithm - is RSA using the RSAwithSHA256
  • Key length - for RSA is 4096 bits.
  • Digest method - SHA-256.
  • Canonicalization algorithm - Canonical XML Version 1.1 (omits comments) 
  • Certificate format - X.509 version 3

Implementation has been done using Apache Santuario 1.5.2 release. To achieve the highest possible security, the public key certificate of trusted signers needs to be imported to the trusted keystore of Wookie. You can access the code at current SVN of Apache Wookie which can be used to generate a detached signatures on any other content too. 


Wookie supports 2 methods of widget deployment that,
  • Drop .wgt into /deploy
  • POST with attachment to /wookie/widgets 
Widgets sent-in both ways are verified  in the same manner starting from W3CWidgetFactory class. It bends the flow through DigitalSignatureProcessor class if the signature verification is turned on in widgetserver.properties file. The processor identifies the signature files inside the widget and try to verify each extracting the relevant public key certificate from Wookie trusted store. According to the settings at widgetserver.properties, it decides whether to reject widget or deploy with a warning in case of a invalid widget found.

In the processor it, 

  • Check for presence of signature file,
  • Categorize them as author or distributor to understand the which content should be addressed in signature,
  • Check whether all content is signed according to the W3C widget digsig spec.
  • Retrieve trusted public key certificate from Wookie trussted keystore
  • Throws exceptions or put warnings when invalid signatures are encountered
  • handle widget deployment accordingly

You can access the code at current SVN of Apache Wookie.


When the digsig-client is run it will show up a Swing UI as follows.

  • Have to select the role of the signer whether author or distributor
  • Then should point to the keystore which stores the relevant private key
  • It's password should also be given followed by private key alias
  • Then if private key password is same as the keystore password and certificate alias is same as private key alias you can leave it blank.
  • Then once you select the widget folder from the file chooser, digsig-client will show the files selected to be signed from the widget according the role. This will automatically skip files starting with '.' and signature files as mentioned in the W3C spec.
  • Then you can give the name of widget 
  • Once signed the <name>.wgt file is stored in the widget path including signed content and generated signature file, being ready to send to deployment as follows. 

In Wookie Server side, administrators need to set the following properties according the security requirement of their context. This is located at widgetserver,properties file.
# digital signature settings
# Set this property to have Wookie check widget digital signatures when
# deploying a widget
# Set this property to determine how Wookie treats widgets with invalid
# digital signatures.
# If set to true, Wookie will not deploy any widgets with invalid
# digital signatures. If set to false, the widget will be imported
# and a warning logged.
# If set to true, Wookie will only deploy Widgets that have valid digital signatures
# AND that each signature uses a trusted certificate located in the trusted keystore,
# disregarding setting the above to false.
# Name of the trusted keystore file
#Password for the trusted keystore file
widget.deployment.trustedkeystore.password = wookie
After that Wookie server will handle the deployment of widgets in a secured manner given that the trusted public certificates are imported into the trusted keystore of the Wookie server.
Following is a sample author signature generated by digsig-client.
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#" Id="AuthorSignature">
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2006/12/xml-c14n11"></ds:CanonicalizationMethod>
<ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"></ds:SignatureMethod>
<ds:Reference URI="build.xml">
<ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"></ds:DigestMethod>
<ds:Reference URI="config.xml">
<ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"></ds:DigestMethod>
<ds:Reference URI="images/background.jpg">
<ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"></ds:DigestMethod>
<ds:Reference URI="#prop">
<ds:Transform Algorithm="http://www.w3.org/2006/12/xml-c14n11"></ds:Transform>
<ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"></ds:DigestMethod>
<ds:Object Id="prop">
<ds:SignatureProperties xmlns:dsp="http://www.w3.org/2009/xmldsig-properties">
<ds:SignatureProperty Id="profile" Target="#AuthorSignature"><dsp:Profile URI="http://www.w3.org/ns/widgets-digsig#profile"></dsp:Profile></ds:SignatureProperty>
<ds:SignatureProperty Id="role" Target="#AuthorSignature"><dsp:Role URI="http://www.w3.org/ns/widgets-digsig#role-author"></dsp:Role></ds:SignatureProperty>
<ds:SignatureProperty Id="identifier" Target="#AuthorSignature"><dsp:Identifier>test</dsp:Identifier></ds:SignatureProperty>

The relevant steps for generating key pairs needed for digital signatures and procedure to import public certificates can be found in this post.
Enjoy with Wookie...............!