OPA for HTTP Authorization

Open Policy Agent[1] is a promising, light weight and very generic policy engine to govern authorization is any type of domain. I found this comparion[2] very attractive in evaluating OPA for a project I am currently working on, where they demonstrate how OPA can cater same functionality defined in RBAC, RBAC with Seperation of Duty, ABAC and XACML.  
Here are the steps to a brief demonstration of OPA used for HTTP API authorization based on the sample [3], taking it another level up.
Running OPA Server First we need to download OPA from [4], based on the operating system we are running on.  For linux, curl -L -o opa https://github.com/open-policy-agent/opa/releases/download/v0.10.3/opa_linux_amd64 Make it executable, chmod 755 ./opa Once done, we can start OPA policy engine as a server.
./opa run --server Define Data and Rules Next we need to load data and authorization rules to the server, so it can make decisions. OPA defines these in files in the format of .rego. Below is a sample …

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...............!


  1. Thanks for sharing details about Apache Wookie W3C Widget Digital Signature Implementation. It looks pretty interesting.I think Wookie is based on the W3C Widgets specification, but widgets can also be included that use extended APIs such as Google Wave Gadgets and OpenSocial.
    Anyway I wish best of luck to you and I believe your project will be successful.
    Good luck!

  2. I really enjoyed reading the complete detail that you have posted about your project. The idea is really very interesting. The above detail helped me a lot and I wish you good luck for your brilliant work out.
    digital signatures

  3. Thanks a lot Tee and all for the encouraging wishes.

  4. This comment has been removed by a blog administrator.

  5. Very efficiently written information. It will be helpful to everyone who will use it, including me. Keep doing what you are doing – I will definitely read more posts. I simply want to say that I am new to weblog and absolutely enjoyed this web site. Almost certainly I’m likely to bookmark your blog. You will absolutely come with impressive well written articles in future. Thanks for sharing with us your web-site.

  6. Thank you for the good write-up. It in fact was an amusement account. Looking forward to see more added agreeable informative blog from you! It’s hard to find high quality writing like yours these days. Great Article, I simply bookmarked this page. Thanks extremely, I appreciate you for making this article available, other website is also done well.

  7. Thanks a lot for such a complete explanation about digital signature. I tried to implement your directives, and I did success since it is so well explained. Amazing !

  8. Great to hear this has been useful and guided you to something successful. I am thrilled to see such good comments here.

  9. This comment has been removed by a blog administrator.

  10. hi Pushpalanka
    thank you for this great blog. It helped me a lot.
    I am facing a problem though.
    As eplained I was successfull in signing my widgets. But whenever I deploy them I get error as:-
    Hot deploy error: widget has invalid manifest - org.apache.wookie.w3c.exceptions.BadAuthorSignatureException: Invalid Author Signature.
    [java] org.apache.wookie.w3c.exceptions.BadManifestException: org.apache.wookie.w3c.exceptions.BadAuthorSignatureException: Invalid Author Signature.
    [java] at org.apache.wookie.w3c.W3CWidgetFactory.processWidgetPackage(W3CWidgetFactory.java:320)
    [java] at org.apache.wookie.w3c.W3CWidgetFactory.parse(W3CWidgetFactory.java:176)
    [java] at org.apache.wookie.w3c.W3CWidgetFactory.parse(W3CWidgetFactory.java:161)
    [java] at org.apache.wookie.server.ContextListener$1$1.fileModified(ContextListener.java:225)
    [java] at org.apache.wookie.util.WgtWatcher.check(WgtWatcher.java:95)
    [java] at org.apache.wookie.server.ContextListener$1.run(ContextListener.java:265)
    [java] Caused by: org.apache.wookie.w3c.exceptions.BadAuthorSignatureException: Invalid Author Signature.
    [java] at org.apache.wookie.util.digitalsignature.DigitalSignatureProcessor.verifyWidget(DigitalSignatureProcessor.java:146)
    [java] at org.apache.wookie.util.digitalsignature.DigitalSignatureProcessor.processDigitalSignatures(DigitalSignatureProcessor.java:110)
    [java] at org.apache.wookie.w3c.W3CWidgetFactory.processWidgetPackage(W3CWidgetFactory.java:287)

    I dont know where I am going wrong as I am new to this.
    Please revert.

  11. Hi,
    I'm glad that my post has helped you.
    Please verify whether the public key of the signing private key is imported to the truststore of the server. The problem may be the public key is not trusted by the server.

  12. Hi Pushpa,
    Thanks for your quick reply.
    Isn't the following command enough for import?
    keytool -import -alias keystore1 -file keystore1.cer -keystore wookieKeystore.jks

    If no, then what else I have to do.

    Please revert.

  13. Hi,
    That is enough.
    So next thing we should verify is, after the signing is done you haven't made any change to the .wgt folder content. If this is also fine, I can't guess it. If it's ok, send me the signed .wgt and the wookieKeystore.jks having the public key of the signing key. I'll check and see what is going wrong.

  14. Hi Pushpa,

    Thanks a lot again.
    I have attached the files and sent you the mail.
    Please look into it and revert.


Post a Comment

Popular posts from this blog

Signing SOAP Messages - Generation of Enveloped XML Signatures

OPA for HTTP Authorization

How to Write a Custom User Store Manager - WSO2 Identity Server 4.5.0