Monthly archives "December 2014"

SSL / TLS REST Server – Client with Spring and TomEE

posted by Roberto Cortez on

When building a system, developers usually disregard the security aspects. Security has been always something very important to worry about, but it’s attracting even higher concerns than before. Just this year we had a few cases like the Heartbleed Bug or the CelebrityGate scandal. This has nothing to do with the post, but are just examples that security really matters and we should be aware of it.

With the increasing popularity of REST services it makes sense that these need to be secured in some way. A couple of weeks ago, I had to integrate my client with a REST service behind https. I have never done it before and that’s the reason for this post. I have to confess that I’m no security expert myself, so please correct me if I write anything stupid.

The Setup

For this example I have used the following setup:

I’m not going into many details about SSL and TSL, so please check here for additional content. Note that TLS is the new name for SSL evolution. Sometimes there is confusion between the two and people often say SSL, but use the newest version of TSL. Keep that in mind.

Don’t forget to follow the instructions on the following page to setup SSL for Tomcat: SSL Configuration HOW-TO. This is needed for the server to present the client with a set of credentials, a Certificate, to secure the connection between server and client.

The Code

Service

Let’s create a simple Spring REST Service:

RestService.java

And we also need some wiring for this to work:

RestConfig.java

web.xml

Please, note the elements security-constraint, user-data-constraint and <transport-guarantee>CONFIDENTIAL</transport-guarantee>. These are needed to specify that the application requires a secure connection. Check Securing Web Applications for Java Applications.

Running the Service

Just deploy the application on the TomEE Server using your favourite IDE environment and access https://localhost:8443/. You should get the following (you might need to accept the server certificate first):

Rest Service Localhost

Note that the browser protocol is https and the port is 8443 (assuming that you kept the default settings in SSL Configuration HOW-TO.

Client

Now, if you try to call this REST service with a Java client, most likely you are going to get the following message and Exception (or similar):

Message: I/O error on GET request for “https://localhost:8443/”:sun.security.validator.ValidatorException:

Exception: Caused by: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

This happens because the running JDK does not have a valid certificate for your server. You can import it, and get rid of the problem, but let’s do something more interesting. We are going to programatically supply a trusted keystore with our server certificate.

This is especially useful if:

  • you are running your code into multiple environments
  • you don’t have to manually import the certificate into the JDK every time
  • if you upgrade the JDK you have to remember about the certificates
  • for some odd reason you don’t have access to the JDK itself to import the certificate

Let’s write some code:

RestClientConfig.java

Here we use Spring RestOperations interface which specified a basic set of RESTful operations. Next we use Apache HTTP Components SSLConnectionSocketFactory which gives us the ability to validate the identity of the server against a list of trusted certificates. The certificate is loaded from the same file used on the server by KeyStore.

RestServiceClientIT.java

A simple test class. We also need a properties file with the keystore file location and password:

config.properties

This should work fine if you used all the defaults.

Running the Test

If you now run the test which invokes the REST service within a Java client, you should get the following output:

Response: <200 OK,Called the get Rest Service,{Server=[Apache-Coyote/1.1], Cache-Control=[private], Expires=[Thu, 01 Jan 1970 01:00:00 WET], Content-Type=[text/plain;charset=ISO-8859-1], Content-Length=[27], Date=[Tue, 23 Dec 2014 01:29:20 GMT]}>

Body: Called the get Rest Service

Conclusion

That’s it! You can now call your REST service with your client in a secured manner. If you prefer to add the certificate to the JDK keystore, please check this post.

Stay tuned for an equivalent for Java EE JAX-RS equivalent.

Resources

You can clone a full working copy from my github repository: REST SSL.

One year of Blog

posted by Roberto Cortez on
tags:

Hi everyone! Exactly one year ago, I’ve launched this blog. Looking into my first post, I’ve written the following:

I have created this blog to share any Java related topics to anyone that may care. For me, it would be useful to improve my English and keep a record of stuff I work and do. I usually forget a lot of stuff!

After one year, I think this is still true. I would like to think that my English improved because of the writing. This blog has now been actually one of my most valuable resources. Even yesterday I was looking into one of my older posts because I couldn’t remember a few details about it.

But more important are the Readers! And that is you! The feedback has been overwhelming positive, and I could not Thank You enough for taking your time to read my stuff.

Blog radcortez One Year

A few numbers:

  • 39 posts
  • 114 comments
  • 83819 page views
  • 166 visiting countries

Most popular posts:

Angular is really popular. I guess I have to write a few more things about it!

My favourite posts:

Final Words

That’s it! I hope that I can write more awesome content for the next year!

Seventh Coimbra JUG Meeting – Forge and First Anniversary

posted by Roberto Cortez on

Last Thursday, 11 December 2014, the seventh meeting of Coimbra JUG was held on the Department of Informatics Engineering of the University of Coimbra, in Portugal. This was a special event, since we had the pleasure to have Koen Aers, the first international speaker to visit our JUG, talk a little bit about a very promising tool: JBoss Forge. This meeting was also our First Anniversary Celebration. That’s right, Coimbra JUG was created last year in December. For this meeting we had around 30 people and a few newcomers.

Coimbra JUG Meeting 7 Session

A few people in the audience had already heard about JBoss Forge, but no one was actively using it. Koen demonstrated the tool capabilities by creating a Java EE application, with a few entities and scaffolded a JSF interface in a short amount of time. Next, added some REST services and showed us a way to generate JPA entities with an existing database schema. Time for a break!

Coimbra JUG Meeting 7 Break

Thanks to some of our sponsors we had a few snacks and beer. Of course, we also had a cake to celebrate our first anniversary.

Back to JBoss Forge, Koen was now showing us how to develop plugins. The attendees seemed very curious and interested to learn about it and the questions were great. A lot of interactions and discussions were generated during the session. I might write something about JBoss Forge in the future.

Here are the materials for the session:

Enjoy!

Acknowledgements

I would like to thanks all the sponsors, that in one way or another contributed to our JUG during our first year:

Coimbra JUG Meeting 7 Sponsors

And of course Koen Aers for taking is time to visit us here in Coimbra. Thank you!

Coimbra JUG Meeting 7 Koen

About Coimbra JUG

Annotations, Annotations Everywhere

posted by Roberto Cortez on
tags:

Annotations became available with Java 1.5 in 2004, ten years ago. It’s hard to imagine our code without this feature. In fact, annotations were first introduced to relieve developers from the pain of writing tedious boilerplate code and make the code more readable. Think about J2EE 1.4 (no annotations available) and Java EE 5. Annotation adoption considerably simplified the development of a Java EE application by getting rid of all the configuration XML. Even today, more annotations are being added to the newest version of Java EE. The idea is to unburden the developer and increase productivity. Other technologies and frameworks use them extensively as well.

Annotations Everywhere

Annotations Everywhere

Let’s see an example on how annotations have simplified our code (from my post about JPA Entity Graphs):

Wait a minute! Simplified? Really? Aren’t annotations supposed to make my code more readable? This example has more annotations than actual code. To be fair, I’m not including getters and setters. Also, some of the annotated code could be better condensed, but it would make the code harder to read. Of course, this is an extreme case. Anyway, I’m happy since I won the title Annotatiomaniac of the Year. Thanks Lukas!

Annotatiomaniac of the Year

We rely in annotations so much that we end up abusing them. It’s funny that annotations in some cases are causing the same problems that they intended to solve.

What if?

Let’s rewrite the previous sample like this:

It sure looks more readable. But these annotations do not exist. Where do they come from?

@LoadWithActors

@LoadWithActorsAndAwards

And so on for the rest. You get the feeling. The idea would be to extract and group annotation metadata into your own custom annotations. Your annotation could then be used to represent all the annotated data in your code, making it easier to understand. It’s like Java 8 Lambdas, read like the problem statement.

Just another example:

Rewritten:

@RestStatelessBean

Usually, I write these annotations once to define the behaviour of my POJO and never look into them again. How cool would be if I could just reuse one annotation for all my Stateless Rest Services?

Another nice effect, is that annotation configuration metadata is not directly tied in the code. Instead it’s abstracted away into a different annotation. In this case, it would be possible to override or replace the values in compile / runtime.

Meta Annotations

I first heard about this concept by David Blevins. He wrote a very good post about these ideas in his Meta-Annotations post and even wrote a possible implementation.

It would be convenient to have plain Java SE support to annotation inheritance, abstraction and encapsulation. It’s a major shift in the way annotations are handled by all the technologies out there. This only makes sense if everyone starts supporting this kind of behaviour.

One might ask, do we really need this feature? Let’s try to weigh in some pros and cons:

Pros

  • Simplified Code.
  • Annotation Reuse.
  • Annotation configuration not directly tied to the code. Values could be overridden.

Cons

  • Another layer of abstraction.
  • Freedom to create custom annotations could obfuscate the real behaviour.
  • Possible to run into some kind of multiple inheritance pitfall.

Conclusion

It’s unlikely that this Meta-Annotations are going to be available in Java SE for the foreseeable future. In Java 9, most of the focus is in Jigsaw. We don’t have much information yet on Java 10, other than Value Types and Generic Specialization. In fact, all these annotation concerns are not really a problem for plain Java SE.

The amount of annotations present in our source files is becoming a problem regarding readability and maintainability. This is especially true for Java EE and other similar technologies. Think about HTML and CSS. If you’re developing an HTML page and you only need a couple of CSS styles, you usually inline them in the elements or include them directly in the page. If you start to have too many styles, then you proceed to extract them into an external CSS file and just apply the style. I do believe that something must be done either by adopting Meta-Annotations or something else. Do you have any other ideas? Please share them!

Resources

Don’t forget to check David Blevins post about Meta-Annotations. He explains this much better than me, including the technical details.

Also a presentation JavaOne EJB with Meta Annotations discussing these ideas by David Blevins.

And what better than to listen David Blevins himself? Java EE 7, Infinite Extensibility meets Infinite Reuse.