Our blog

20 Apr 2015
by cvringer

Securing Milton Webdav with JAAS

I was working on our Document Management System, playing around with another webdav possibility. Our DMS uses JackRabbit for webdav.

Although it has been working fine for about 6 years now, it’s been causing a lot of overhead. So i looked into Milton (http://milton.io) which should be a nice lightweight solution. One can map it’s own model to Milton and thus enable webdav. For us, our model (in the database) is translated intro a nice webdav solution.

To get a feeling about Milton, you can download milton-anno-ref. It’s a working implementation, and runs out of the box. Note: To enable full Dav Level2 you need a (trial) license. Read more HERE.

Now, when you use Milton, you probably want to run it on Tomcat, or some application server. Maybe you already use something like JAAS. So how do you configure Milton to not use it’s own authentication mechanism, but the container managed one?

I’ll describe how you can use JAAS, and run it on Jetty, Tomcat or Glassfish.¬†Ready? Let’s go then.

First: When you downloaded and installed Milton onto your favorite IDE, you have to disable Milton’s own securitymanager. The SecurityManager is injected in the default Configurator, so we have to build our own configurator. Here’s the code:

As you can see, we disable security by injecting a NullSecurityManager into the HttpManagerBuilder. This disables any authentication and authorization. Next, we tell Milton to use this Configurator. We also configure the security element in our web.xmlThis tells the container to authenticate all requests and give access to any authenticated user with the role milton-user. An OPTIONS request is always allowed. So, if you run Milton now, the container will authenticate, and once authenticated Milton can do it’s work.

 

In our DMS, ACL is not controlled by Milton, but in the database. So the query result depends on the user and the roles and permissions that user has in the database. For every query we need to know the logged-in user (Principal). In Milton getting the Principal is easy. Annotated methods can be extended adding the Request parameter. From this request you can get the Principal. Here’s how:

20 Apr 2015
by cvringer

Connect to Twinfield using Java

Twinfield has an extensive webservice API available. It has documented how to connect for popular technologies like C, .net and php. Unfortunately there is no Java tutorial available, so i wrote it down here. First, i’ll explain how to setup a Java project in Intellij using Spring-ws and maven. Of course you can use your own IDE for this. In a next entry i will explain how to create and abandon a session, and how to execute requests. Lets start!

 

First of all: If you want to download the full example and get quick and dirty in minutes, you can do that HERE. No need to further explore this page. Glad i could help!

 

OR….

 

Get to know a little more of the working code below, and build the bastard for yourself.
Many developers have precedeeded you. I’m sure you can build it too!

 

Step one: Create a maven project: In your IDE you can create a new maven project. In Intellij you will use file/new Project/Spring application. This will result in a maven-structured project, which contains a pom.xml file with some spring dependencies in it. You can also use command-line maven to create a new project. Details are HERE

 

Next, fill your pom with dependencies. An full pom example is HERE

 

Step two: Import the wsdl for session into your project and save it in scr/main/resources/wsdl. The maven-jaxb2-plugin plugin will take care of generating objects from the wsdl. If you run mvn clean install from your project root directory, Twinfield objects will be generated in your target directory.

 

For the coding part:
You will need a Spring configuration. I use an AnnotationBasedConfiguration class for this.

Next write the WebServiceClient implementation. A Unit test example is HERE (thanks #Kees). This example uses a
SessionDetails wrapper object to store the requested sessionId and actionUrl.

 

Note that the webserviceclient sets a SOAP Action variable. This variable is required by Twinfield and should define the action (Logon or Abandon). Now you have Twinfield connection, you can query or send XML to Twinfield.

 

Good luck coding!

© Keienberg Consultants