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
| @Controller @RequestMapping("/") public class RestService { @RequestMapping(method = RequestMethod.GET) @ResponseBody public String get() { return "Called the get Rest Service"; } } |
And we also need some wiring for this to work:
RestConfig.java
| @Configuration @EnableWebMvc @ComponentScan(basePackages = "com.radcortez.rest.ssl") public class RestConfig {} |
web.xml
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 32 33 34 35 36 37 | <?xml version="1.0" encoding="UTF-8"?> <web-app version="3.1" xmlns="http://xmlns.jcp.org/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd"> <servlet> <servlet-name>rest</servlet-name> <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class> <init-param> <param-name>contextClass</param-name> <param-value>org.springframework.web.context.support.AnnotationConfigWebApplicationContext</param-value> </init-param> <init-param> <param-name>contextConfigLocation</param-name> <param-value>com.radcortez.rest.ssl</param-value> </init-param> <load-on-startup>1</load-on-startup> </servlet> <servlet-mapping> <servlet-name>rest</servlet-name> <url-pattern>/</url-pattern> </servlet-mapping> <security-constraint> <web-resource-collection> <web-resource-name>Rest Application</web-resource-name> <url-pattern>/*</url-pattern> </web-resource-collection> <user-data-constraint> <!-- Needed for our application to respond to https requests --> <transport-guarantee>CONFIDENTIAL</transport-guarantee> </user-data-constraint> </security-constraint> </web-app> |
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):
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
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 32 33 34 35 36 37 | @Configuration @PropertySource("classpath:config.properties") public class RestClientConfig { @Bean public RestOperations restOperations(ClientHttpRequestFactory clientHttpRequestFactory) throws Exception { return new RestTemplate(clientHttpRequestFactory); } @Bean public ClientHttpRequestFactory clientHttpRequestFactory(HttpClient httpClient) { return new HttpComponentsClientHttpRequestFactory(httpClient); } @Bean public HttpClient httpClient(@Value("${keystore.file}") String file, @Value("${keystore.pass}") String password) throws Exception { KeyStore trustStore = KeyStore.getInstance(KeyStore.getDefaultType()); FileInputStream instream = new FileInputStream(new File(file)); try { trustStore.load(instream, password.toCharArray()); } finally { instream.close(); } SSLContext sslcontext = SSLContexts.custom().loadTrustMaterial(trustStore, new TrustSelfSignedStrategy()).build(); SSLConnectionSocketFactory sslsf = new SSLConnectionSocketFactory(sslcontext, new String[]{"TLSv1.2"}, null, BROWSER_COMPATIBLE_HOSTNAME_VERIFIER); return HttpClients.custom().setSSLSocketFactory(sslsf).build(); } @Bean public static PropertySourcesPlaceholderConfigurer propertySourcesPlaceholderConfigurer() { return new PropertySourcesPlaceholderConfigurer(); } } |
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
| @RunWith(SpringJUnit4ClassRunner.class) @ContextConfiguration(classes = RestClientConfig.class) public class RestServiceClientIT { @Autowired private RestOperations rest; @Test public void testRestRequest() throws Exception { ResponseEntity<String> response = rest.getForEntity("https://localhost:8443/", String.class); System.out.println("response = " + response); System.out.println("response.getBody() = " + response.getBody()); } } |
A simple test class. We also need a properties file with the keystore file location and password:
config.properties
| keystore.file=${user.home}/.keystore keystore.pass=changeit |
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.
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.
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!
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.
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!
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:
And of course
Koen Aers for taking is time to visit us here in Coimbra. Thank you!
About Coimbra JUG
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
Let’s see an example on how annotations have simplified our code (from my post about JPA Entity Graphs):
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 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 | @Entity @Table(name = "MOVIE_ENTITY_GRAPH") @NamedQueries({ @NamedQuery(name = "Movie.findAll", query = "SELECT m FROM Movie m") }) @NamedEntityGraphs({ @NamedEntityGraph( name = "movieWithActors", attributeNodes = { @NamedAttributeNode("movieActors") } ), @NamedEntityGraph( name = "movieWithActorsAndAwards", attributeNodes = { @NamedAttributeNode(value = "movieActors", subgraph = "movieActorsGraph") }, subgraphs = { @NamedSubgraph( name = "movieActorsGraph", attributeNodes = { @NamedAttributeNode("movieActorAwards") } ) } ) }) public class Movie implements Serializable { @Id private Integer id; @NotNull @Size(max = 50) private String name; @OneToMany @JoinColumn(name = "ID") private Set<MovieActor> movieActors; @OneToMany(fetch = FetchType.EAGER) @JoinColumn(name = "ID") private Set<MovieDirector> movieDirectors; @OneToMany @JoinColumn(name = "ID") private Set<MovieAward> movieAwards; } |
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!
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:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 | @MovieEntity @FindAll @LoadWithActors @LoadWithActorsAndAwards public class Movie implements Serializable { @Id private Integer id; @Name private String name; @MovieActors private Set<MovieActor> movieActors; @MovieDirectors private Set<MovieDirector> movieDirectors; @MovieAwards private Set<MovieAward> movieAwards; } |
It sure looks more readable. But these annotations do not exist. Where do they come from?
@LoadWithActors
| @NamedEntityGraph( name = "movieWithActors", attributeNodes = { @NamedAttributeNode("movieActors") } ) public @interface LoadWithActors {} |
@LoadWithActorsAndAwards
| @NamedEntityGraph( name = "movieWithActorsAndAwards", attributeNodes = { @NamedAttributeNode(value = "movieActors", subgraph = "movieActorsGraph") }, subgraphs = { @NamedSubgraph( name = "movieActorsGraph", attributeNodes = { @NamedAttributeNode("movieActorAwards") } ) } ) public @interface 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:
| @Named @Stateless @TransactionAttribute(TransactionAttributeType.SUPPORTS) @ApplicationPath("/resources") @Path("wowauctions") @Consumes(MediaType.APPLICATION_JSON) @Produces(MediaType.APPLICATION_JSON) public class WoWBusinessBean extends Application implements WoWBusiness {} |
Rewritten:
| @RestStatelessBean("wowauctions") public class WoWBusinessBean extends Application implements WoWBusiness {} |
@RestStatelessBean
| @Named @Stateless @TransactionAttribute(TransactionAttributeType.SUPPORTS) @ApplicationPath("/resources") @Path("#{path}") @Consumes(MediaType.APPLICATION_JSON) @Produces(MediaType.APPLICATION_JSON) public @interface RestStatelessBean { String value() default "#{path}"; } |
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.
After attending Devoxx, I followed directly to Sofia – Bulgaria to attend one of the most popular conferences in the region called Java2Days. Java2Days started 6 years ago by Iva, Nadia and Yoana (yes, they are all girls). They have been doing a terrific job organizing and growing the conference over the last few years. This edition counted more than 800 attendees and 25% were women! For years, the tech world has been trying to attract more women is a world mostly dominated by men. For instance, Devoxx women’s attendance was only 5%. Maybe the tech world could extract a few lessons from Java2Days on how to attract more women.
This was my first time at Java2Days and I really enjoyed my time there. I was also invited as a speaker, to talk about the same sessions I’ve presented at JavaOne: Java EE 7 Batch Processing in the Real World with Ivan Ivanov and The 5 people in your organization that grow legacy code.
Sessions
Java2Days kicked out with a packed room to listen to a very good inspirational keynote by John Davies about Technology Landscape and Innovation. I’ve retained the following words: “If you don’t innovate others will”. Check the full keynote here.
Most of the speakers were local guys (speaking in English) and they delivered great content. Java2Days is a perfect place for less known speakers to show their skills (myself included).
I’ve spent a lot of time hacking, but also attended a few sessions. These are my top 3 sessions (from the ones I have attended):
Unfortunately, the sessions were not recorded, but you can check the slides here.
My Sessions
After practicing a bit more on the presentations following JavaOne I was more comfortable doing the sessions. I’m very happy with the result. Attendees seemed interested and the rooms were full for both sessions. Thank you everyone that attended the sessions.
Here are the slides:
Community
The community was amazing! Very friendly and happy to have people from outside of Bulgaria. Also a lot of Macedonians in the conference, which invited me to attend their own event next year. If I’m available, I will gladly attend.
I’ve also noticed that some attendees don’t feel comfortable enough approaching speakers. This is nothing new, since it also happens in other conferences, but I would like to leave this message: feel free to ALWAYS approach me and engage in conversation with me. I’m going to be very disappointed if I’ve missed the opportunity to engage with someone, because he or she couldn’t get to me. Please do it next time!
Final Words
Java2Days was a great conference. I was surprised with the atmosphere, which was awesome and friendly. I was very well treated by everyone, and I already have plans to return next year. If you find the time, don’t hesitate to pay Java2Days a visit.
A big thanks to Iva, Nadia and Yoana for having me at Java2Days and for being great hosts to me. Also a special thanks to Ivan Ivanov for convincing me to go there and for his awesome hospitality. Cya next year!
