With the rise of the micro-service architecture, we have seen also a shift from SOAP to REST as the means of exchanging data between parties. REST and JAX-RS are gaining a lot of popularity outside the micro-service world, also.
And if you compare the effort to use them, it is no surprise to see such a shift.
At EclipseCon in the Cloud-Native Java track, to I showed you how to use JWT tokens and HTTPS Signatures to securely replace your SOAP usage by JAX-RS. You can find the video at the bottom of this post.
We can’t just replace all our SOAP endpoint with JAX-RS endpoints. From a technical point of view, there are some differences between the technologies (which are most of the time quite manageable) but there is one aspect which is missing in JAX-RS - and that is security.
Within the SOAP framework, we have a variety of tools for security, including the WS-Security extension. It gives you encryption, process to process integrity, certificates, etc - but JAX-RS only offers the capabilities of the underlying protocol.
We can use the default SSL functionality to add security within JAX-RS, and although SSL provides some very good functionality, there are a few attention points and limitations.
How do you track your ‘sender’ and what is the impact of SSL interruption on the integrity guarantee that you should provide?
For identifying the other endpoint of your JAX-RS connection, Client Certificates can only be used when the number of clients is stable and doesn’t change much.
And to overcome SSL interruption, we need something on the process level to guarantee integrity and prevent the server from handling this.
Secure JAX-RS Presentation at EclipseCon
The ‘Secure JAX-RS’ presentation goes deeper into these topics and shows how you can use JWT tokens and HTTPS Signatures to securely replace your SOAP usage by JAX-RS.