April recap: JAX 2018 and having a bestselling book on Amazon

We’re only in for 4 months in 2018 and I can not believe all the stuff already happened. I did one final iteration of my talk about Spring Boot starters at JUG Saxony in Leipzig. It was their 100th meet up and the welcomed me with great hospitality. I was very happy to meet my friend Oliver there. Just a day later, several colleagues from INNOQ and I met at our Berlin office for a workshop about cherishing communication by Spring Boot Book started to appear in physical form on Amazon and other shops just in time for JAX.

My colleagues Martin and Simon at the booth:


Thanks a lot to Ralf for helping us with the booth. Also for challenging me with a complicated topic which should be way more simple:

I had a fresh new talk with Michael Plöd about Spring Boot 2 hot topics on a ridiculously large stage:


The talk went very well and spiked the sales of the book a lot, resulting in this:


I’m actually a bit overwhelmed. The book hitting place #478 in all German books by the end of Thursday was a blast. Thank you kind people out there for supporting me. Keep sending me all those unwrapping pictures, I’m already looking forward to your feedback. Maybe in form of a review?

JAX itself ended for me coaching in an architecture retreat with Susanne, Peter, Jörg and Eberhard. It started a bit out of my comfort zone but it was a good thing todo.

Back to the book:

Analysing a book

The following content is a Jupyter notebook. It’s an embedded Gist. You can clone it and use it as a base for your own experiments.

| Comments (0) »

28-Apr-18


March 2018 recap

March 2018 was a damn crazy month. It began with the release of Spring Boot 2.0 which meant big congratulations to the whole Spring Boot team and more work on my side: I’ve updated all examples for the Spring Boot Buch, went through the manuscript one last time and sent it to my publisher. I’ve written the book with LaTeX, using Minted and Pygments for syntax highlighting and I think the people at DA-TEX did a stellar job for the final typesetting:



Also thanks to René Schönfeldt at dpunkt for your support during the last year and getting that thing to the printing plant in March. Also many thanks to Eberhard Wolff. He helped me with valuable feedback and mentoring throughout the last year. The book should hit stores any time soon now. You may get it at Amazon or an ePub version at dpunkt plus.

Dating back to November of last year, Dominik asked me to write about Spring Boot 2 for JAXenter. Those articles came out in March, too:

Those post are German but are being translated for the english portal as well at the moment. I’m quite impressed how many rubber boot pictures are out there.

And then there was JavaLand 2018. I have been to every installment of JavaLand, have been involved two times in the program committee, spent last year as a mentor at JavaLand4Kids and this year, I could be a mentor for my friend Felix who spoke about generating tests in the newcomer track in the fully booked tent:



Thanks a lot for putting your trust in me, Felix! Inspired by the success we had and Timothées talk about mentoring, I’d love to do that again.

I myself feel blessed and lucky. 2 years ago, I was invited to speak at Spring I/O 2016 about Spring Boot starter. First public talk ever and from there on the ride got a bit crazy. 15 more talks leading to this audience at JavaLand and I’m still totally stocked:



Thank for being there!

Last but not least: Several services I worked on the last 3 months went into production. One based on a mix of Jersey/JAX-RS/HK2, two Spring Boot based. I’m totally thrilled how easy one could integrate Spring Boot with just a few starters into a foreign ecosystem.
The team basically could still write JAX-RS-Resources as used too and enjoying all the good stuff that comes with the Spring ecosystem, mainly Spring Data repositories and especially Spring Integration. Incredible how easy and clean flows can be defined by the Java-DSL. I was asked what the advantage of Spring Boot was for the new services compared to the old stack: Even though I had to write some integration points, we could work on a much faster pace, having to deal a lot less with plumbing code and concentrate on the business value.

April will start with vacation for me and hopefully, I’ll finally hold a copy of my book in my hands during the next days.

| Comments (0) »

31-Mar-18


Code examples in your Keynote or Powerpoint-Presentations

Code examples, when nicely executed, are a good and valid alternative to live coding. In the end, when you’re not Venkat or Josh, what is live coding anyway? Most of the time one does rehearse the code anyway 😉

Before you add code to your slides, have a look at this presentation by Uri Native called codeware.

One option to get nice code into your presentation regardless wether you’re using a tool like Powerpoint, Google Slides or Reveal.JS are images. Carbon is one way to create nice images from code.

I personally like (or, TBH dislike the least) Keynote, so images are not the first format I’d chose, especially if I want to generate PDFs from presentations who’s code can be copy and pasted. Therefor I run with highlight by André Simon.

Install it with Homebrew brew install highlight and then you can use it’s RTF output option to create RTF data that can be pasted into Keynote (or Powerpoint) as you like. Combine it with pbpaste and pbcopy for an easy workflow without intermediate files. pbcopy is a terminal tool that copies content piped to it into your macOS clipboard.

Here are some examples:

# Highlight a Java source file and copy it's content to your clipboard
highlight DemoWebFlux.java --style zellner -O rtf | pbcopy
# Paste unformatted JSON code, format it and then highlight and copy it
pbpaste | python -m json.tool | highlight --style zellner -O rtf --syntax json | pbcopy

I think you get the point. Just insert the formatted RTF data into your deck. Most of the time I try to increase the font size as much as possible.

I’m using this in my slides and I am pretty happy with it.

| Comments (1) »

10-Mar-18


Revised Actuators in Spring Boot 2

This post has been featured on This Week in Spring – February 20th, 2018 and I’m feel honored to be referred as “Spring community legend” but even more so to be listed next to a lot of people who’s work I use on a daily basis. Thanks, Josh.

Tim from Ordina posted a nice blog recently, about Visualizing your Spring Integration components & flows. As it happens, I’m currently using Spring Integration as well and find the Integration Graph really useful.

Tim recommends just adding the integretion-http component, but I cannot do this because the project uses JAX-RS and Jersey.

Here is where the revised Actuator support in Spring Boot 2 really shines: Actuator isn’t depending on a specific technology anymore, like Spring MVC, Jersey or for that matter, Spring WebFlux.

Existing and custom endpoints are technology agnostic and can be written without thinking about Spring MVC or Jersey.

Here’s what you need todo to provide Springs Integration Graph pretty much like @EnableIntegrationGraphController but without tying yourself to a specific web technology and at the same time, profiting from all the infrastructure behind Actuator:

import org.springframework.boot.actuate.autoconfigure.web.ManagementContextConfiguration;
import org.springframework.boot.actuate.endpoint.annotation.Endpoint;
import org.springframework.boot.actuate.endpoint.annotation.ReadOperation;
import org.springframework.boot.actuate.endpoint.annotation.WriteOperation;
import org.springframework.context.annotation.Bean;
import org.springframework.integration.support.management.graph.Graph;
import org.springframework.integration.support.management.graph.IntegrationGraphServer;
 
/**
 * Provides insights into the integration graph and flow.
 *
 * @author michael@simons.ac
 */
@ManagementContextConfiguration
public class IntegrationGraphEndpointConfig {
 
   @Bean
   public IntegrationGraphServer integrationGraphServer() {
      return new IntegrationGraphServer();
   }
 
   @Bean
   public IntegrationGraphEndpoint integrationGraphEndpoint(final IntegrationGraphServer integrationGraphServer) {
      return new IntegrationGraphEndpoint(integrationGraphServer);
   }
 
   @Endpoint(id = "integration")
   static class IntegrationGraphEndpoint {
 
      private final IntegrationGraphServer integrationGraphServer;
 
      public IntegrationGraphEndpoint(IntegrationGraphServer integrationGraphServer) {
         this.integrationGraphServer = integrationGraphServer;
      }
 
      @ReadOperation
      public Graph getGraph() {
         return this.integrationGraphServer.getGraph();
      }
 
 
      @WriteOperation
      public Graph rebuildAndGetGraph() {
         return this.integrationGraphServer.rebuild();
      }
   }
}

@ManagementContextConfiguration is a specialized configuration that only deals with management endpoint config. It creates an instance of IntegrationGraphServer and passes it on to an IntegrationGraphEndpoint which is marked as such. The endpoint has a read and a write operation, the later mapping automatically to a POST-request.

Note: You should register your custom endpoint configuration in /META-INF/spring.factories. The management endpoints can be configured to live in a different Spring context and the specialized configuration may not be part of regular auto configuration. For the example above that would look something like this:

org.springframework.boot.actuate.autoconfigure.ManagementContextConfiguration = \
  your.package.IntegrationGraphEndpointConfig

The above endpoint will work only in the same context as the main application, as IntegrationGraphServer needs access to the application context containing your flows. But I have the impression I’ve successfully nerd-snipped Tim.

And just like that, I can build upon Tims nice D3.js based Spring-Integration getting the data from /actuator/integration.

This and more is part of the upcoming German Spring Boot Buch.

| Comments (0) »

13-Feb-18


Spring Security 5: New password storage format

Spring Security 5 has been out for some days now. People on Spring Boot 1 or plain Spring must manually upgrade their dependencies at the moment to notice the new kid on the block. But with Spring Boot 2 Spring Security 5 will be the default for new applications but also for applications that are migrated.

For me as the author of the upcoming Spring Boot Buch (Which you can preorder here) the migration turned out to be pretty hard (hard as in “I had to rewrite lots of examples and text”). The Spring Boot team changed a lot of the “magic” defaults in regard of security and also Actuator security. I’m not saying I don’t like the changes, quite the contrary actually, but it just took some time.

In this post I’m gonna explain the changes in the way password encoding works in Spring Security 5. Most certainly your application will be affected in some way if you upgrade to Spring Boot 2. I will explain migration scenarios if you already have secure hashes or none at all, but also an interesting way of converting insecure hashes to secure hashes and not only migrating them in the sense that they are usable with Spring Security 5 again.

Modernized Password encoding

Whether a password hash is secure or not is in constant flux. There was a time way back then when even a MD5-Hash was regarded secure. Long gone. SHA-1 and SHA-256: Insecure. Either there have been collisions or huge enough rainbow tables, it’s a constant “battle”. In Spring Security those things have been dealt with through a concept of PasswordEncoder. Historically it came from the org.springframework.security.authentication.encoding. The package from that interface has been deprecated for some time now and it’s finally gone from Spring Security 5. A good thing, as “encryption” does not depend on “authentication”. I really wish other frameworks and especially applications would do this kind of housekeeping more often.

So that’s the first thing taking in regard when upgrading to Boot 2: Those encoders are gone. If you’re user details system depends on something like the old ShaPasswordEncoder or Md5PasswordEncoder, you have to do an active migration. The algorithms are still available, but adapted to the current PasswordEncoder-interface residing in org.springframework.security.crypto.password. However, they are all deprecated to mark them as insecure.

A framework like Spring Security can only introduce breaking changes like this once in while, so the team behind Rob Winch made that one count.

What is a good, new password encoder for replacing the old default NoOpPasswordEncoder? You’d say BCryptPasswordEncoder? Nope, not really. That would tie everything again to a specific implementation. Spring Security 5 defaults now to DelegatingPasswordEncoder.

Delegating means being able to use multiple implementations to

  • encode new passwords
  • validate passwords in old and new formats
  • change encoding in the future

The encoder introduces a new password storage format for that purpose. It looks like {id}encodedPassword where {id} represents a logical name of a specific encoder and encodedPassword the actual hash.

The delegating encoder implements the following logic for matching:

  • If there is a known ID for an encoder, use that one to verify the password
  • If there is an encoder configured for having no id, use that, otherwise throw an exception

And for encoding: New passwords are encoded with the encoder identified with a parameter to the constructor of the delegating encoder.

That means you have to do an active migration in most situations.

Migration scenarios

You have been relying on the old default NoOpPasswordEncoder

That means that your passwords are stored in plain text. A bad situation in most cases. Creating an instance of NoOpPasswordEncoder and thus replacing the default delegating encoder allows you to postpone migrations of your passwords to a later date. The next better solution would be prefixing all existing passwords with {noop} and keeping the default encoder of Spring Security 5.

Best option in this case is actually hashing all existing passwords in a a batch run (i.e. in the most simple form of an ApplicationRunner instance) by using the default encoder instance like this:

String encoded = passwordEncoder.encode(plainTextPassword);

You’ll end up with bcrypt-hashed passwords.

Your passwords are already encoded (without a salt source)

Two options here: By all probability you are aware which hash you’re using and are able to update your hashed passwords to include the prefix.

If you you instantiate your password encoder like this

PasswordEncoderFactories.createDelegatingPasswordEncoder();

you get encoders for those prefixes as of Spring Security 5.0:

Map<String, PasswordEncoder> encoders = new HashMap<>();
String encodingId = "bcrypt";
encoders.put(encodingId, new BCryptPasswordEncoder());
encoders.put("ldap", new LdapShaPasswordEncoder());
encoders.put("MD4", new Md4PasswordEncoder());
encoders.put("MD5", new MessageDigestPasswordEncoder("MD5"));
encoders.put("noop", NoOpPasswordEncoder.getInstance());
encoders.put("pbkdf2", new Pbkdf2PasswordEncoder());
encoders.put("scrypt", new SCryptPasswordEncoder());
encoders.put("SHA-1", new MessageDigestPasswordEncoder("SHA-1"));
encoders.put("SHA-256", new MessageDigestPasswordEncoder("SHA-256"));
encoders.put("sha256", new StandardPasswordEncoder());

that means you can prefix your hashed passwords like {SHA-256}encodedPassword and you’re okayish to go. Okayish because you are now able to live on with insecure hashes. Nice thing here is that you can achieve by just updating all passwords at once, for example just using an SQL-query.

The Second option instead of migrating without touching the passwords themselves is this:

PasswordEncoder passwordEncoder = PasswordEncoderFactories.createDelegatingPasswordEncoder();
passwordEncoder.setDefaultPasswordEncoderForMatches(new MessageDigestPasswordEncoder("SHA-256"));

This way you won’t have to update your passwords as the delegating encoder has a fallback. New passwords would be encoded with bcrypt then.

That leads me to the third scenario

Rehashing and upgrading passwords

To rehash an existing password one has to know the plain text as all those hashes are one way functions. You just can invalide all accounts and force all users to change their password next time they login or you can do this automatically. If you want to do this automatically, you the the clear text password. The one and only moment in time to retrieve that is when a user authenticates against your system.

A word of warning: This can be insecure and normally, Spring Security prevents the credentials of a username and password authentication token dangling around.

Following is a migration scenario from a real bullsh*t encoder to a secure system. The author of the encoder was so bad that he even didn’t realize that he has been using a reversible hash all the time! (I kid you not, I actually have seen things like this in the not so distant past! (and no, it wasn’t me)).

The following example code is part of this repository michael-simons/passwordmigration. All beans are configured in the nested SecurityConfig class. Passwords have been encoded with an encoder called BSPasswordEncoder for a reason. The author realized that hashing passwords this way is very, very bad and wants to update them. He configures the delegating password encoder like this:

Please read through the comments, they are part of the story!

The current user and password repository comes from a database, but imagine for a second it’s something like this, so you can see the insecure password hash (you probably can rehash them without cleartext, can’t you?):

That user details service can actually be anything, it just illustrates stuff here. Next the system has to be hooked to Spring Securities event system, which fires successful and failed logins:

You than have to instantiate a WebSecurityConfigurerAdapter that connects the dots. Be careful: With Spring Boot 2.0 this turns Boots magic in regard to security off and all defaults come from Spring Security itself:

The last missing bit is a listener that is notified when a user logs in. It can look like this:

Summing this up: This is a scenario that shouldn’t be live for all the time in the world. I used it in my private project Daily Fratze around 2009 when I migrated all old SHA-1 hashes to BCrypt. It takes some time until all users have been logged in at least once. Maybe you don’t even get them all, but then you can still reset their passwords.

(Featured image on this post by portal gda.)

| Comments (3) »

13-Jan-18