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 --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 (2) »


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;
 * Provides insights into the integration graph and flow.
 * @author
public class IntegrationGraphEndpointConfig {
   public IntegrationGraphServer integrationGraphServer() {
      return new IntegrationGraphServer();
   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;
      public Graph getGraph() {
         return this.integrationGraphServer.getGraph();
      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 = \

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) »


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


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 (5) »


Use Keycloak with your Spring Boot 2 application

This post has been featured in the 7th anniversary edition of This Week in Spring – January 2n, 2018.

Important updates on March 22nd, 2018: Thanks to valid feedback from friends and colleagues Stéphane and Jochen and in the light of the high interested in this post, I have updated the demo. I basically removed all the boilerplate. With Spring Boot 2 final and Spring Security 5 final, you can use OAuth2 login from within a Boot-application agains Keycloak without the need of a key cloak starker or any boilerplate code. All you need is a sane configuration. Due to the nesting of the needed properties, I switched to YAML.

Here’s a short post how to authenticate against Keycloak from within a Spring Boot 2 application. For Spring Boot 1.5.x there’s a community adapter from the Keycloak-team that takes the burden from you, but this adapter is not yet ready for Spring Boot 2 and Spring Security 5.

I had the following requirements for the setup I am gonna present:

  • Manage users outside one application (i.e. be ready for a bunch of services): Realized with Keycloak
  • Full integration with Spring Security, especially method security
  • Funktional with server side rendered Thymeleaf or other template systems supported by Spring Boot

Here is the fully functional demo project: keycloakdemo. I am not replicating some comments from the sources in the following paragraphs.

With Spring Boot 2 comes Spring Security 5 and the first class support for OAuth Login: New feature OAuth2-Login. That means one doesn’t need separate modules anymore. But to make this work, it’s not enough to have spring-boot-starter-security on the class path, you’ll need two more dependencies:

I’ll spare you the details on how to setup Keycloak and how to create a realm and what a realm is. Keycloak has an excellent documentation about that and the screenshots from the one existing tutorial on how to use the Spring Boot adapter have been copied around anyway, along with that post. The realm I used in the demo is part of the repo: test-realm.json. It’s easy to import into Keycloak.

Next step, prepare your application as usual, that is: Annotate your Main-class with @SpringBootApplication. Then configure your client registration together with Keycloak as the provider for the client as described in there in the documentation:

The first two properties are reused in the registration below so that I don’t have to copy them all over the place. This configuration creates a client registration for you. If you need more control, the documentation is there to help you: About client registration.

And now you’re ready to configure your security as usual with the added, new option .oauth2Login().

The following controller together with a simple Thymeleaf template is just for demoing purposes:

Assuming you have a Keycloak server running on port 8080, you can checkout the above linked project, build it with Java 9 and run it on port 8082. Open http://localhost:8082, hit login and you should be redirected to your Keycloak instance and back after a successful login.

Needless to say that this setup works well with other OAuth 2 providers.

| Comments (15) »


2017: It’s all about people

It’s the time of the year to write some recaps. I did this last year and the year before and I will continue that.

We live in highly technologized world, but what’s it all about if not people?

That picture was taken by Stephen Chin at the last day of JCrete 2017 and pretty much sums up the last year. If you click the link and look closely, you’ll find me right behind Heinz. I remember chatting with Heinz at the end of 2016 and the possibility of joining JCrete for one time and 7 months later, it actually happened. Incredible. Even if my first book arc42 by example has now been sold nearly 1500 times, that wouldn’t qualify me. Also, I am no Java Champion that would have qualified me and so I was very happy about the fact that JCrete opened up for more visitors. As written in the recap linked above: A once in a lifetime experience.

We organized eight talks at EuregJUG in 2017: Axel Fontaine, Johan Janssen, Michael Plöd, Stefan Tilkov, Mark Heckler, Maaike Brinkhof, Philipp Krenn and Mattias Weßendorf. I am incredible grateful for the success of this user group. I met new and old friends and have the feeling that I have connected some people.

I myself spoke at eight different meetups, user groups and conferences and I plan to continue that. It really enriched my life.

Yesterday I hopefully committed the last big fixes to Spring Boot Buch. My publisher and I agreed that it’s better to wait with publishing until Spring Boot 2 is final. It’s a bit annoying as I want to get this of my chest, but better for the overall quality. If you’re interested about the making of this, I have tagged all the posts about the book accordingly. As I already have published all examples to GitHub (and also did some contributions to other stuff throughout the year), my contributions chart looks very nice this year:

My plans for next year: Focus even more on communication and connecting to and with people. My impressions from current projects are: We have so much technology to solve problems but more often than not, problems that needs to be addressed are not so much of technical but people nature. My German post at INNOQ is mainly about that topic.

Following are some impressions from last year:

Getting wasted with Axel on Belgium beer in Aachen and opening Spring Community Meetup with Michael Plöd in Munich the next day:


“Playing” with Johanns Lego, recapping the event with Franz, enjoying Marks talk with my wife Christina and meeting Vlad in Cluj:


With Joe, Josh, Mark and Simon from the Spring team at Pivotal at Spring I/O in Barcelona:

At the same conference with Ingo, Sergi and Kevin:

Impressions from JCrete. Thanks to for your company throughout the week, to Felix for good conversations and Heinz for inviting me:


With Chris, Felix, Jürgen and Philipp:

And certainly not forgetting my new colleagues at INNOQ:

2017 was a good year with a lot of changes, but as my friends at Pivotal say “The only constant is change”, it was a good year. I’m looking forward to the next, having my first printed book published and meeting new and old friends and doing hopefully good work. Please take care of yourself, try to relax some times and step back a bit from the display and enjoy life and the people within.

| Comments (0) »