Thursday, July 13, 2017

[OT] I Work with CXF and I Want It That Way

The time has come for a regular OT post.

The journey of the software developer is always about finding the home where he or she can enjoy being every day, can look forward to contributing to the bigger effort every day.

In addition to that the journey of the web services developer is always about finding the web services framework which will help with creating the coolest HTTP service on the Web. We all know there are many quality HTTP service frameworks around.

My software developer's journey so far has been mostly about supporting one of such web services frameworks, Apache CXF. It has been a great journey.

Some of you helped by using and contributing to Apache CXF earlier, some of you are long term Apache CXF users and contributors, preparing the ground for the new users and contributors who are yet to discover CXF.

No matter which group you are in, even if you're no longer with CXF, I'm sure you've had that feeling at least once that you'd like your CXF experience last forever :-).

Listen to a message from the best boys band in the world. Enjoy :-)

  


Monday, July 3, 2017

Multiple JWE Encryptions POC With Apache CXF in two hours

The summer has been great so far, and as usual, instead of watching yet another sport event final, you've decided to catch up with your colleagues after work and do a new round of the Apache CXF JOSE coding. Nice idea they said.

The idea of  creating an application processing the content encrypted for the multiple recipients has captured your imagination.

After reviewing the CXF JWE JSON documentation you've decided to start with the following client code. This code creates a client proxy which posts some text.

JWE JSON filter registered with the proxy will encrypt whatever the content the proxy is sending (does not have to be only text) only once, and the content encrypting key (CEK) will be encrypted with the recipient specific encrypting keys. Thus if you have 2 recipients then CEK will be encrypted twice.

Registering the jwejson1.properties  and jwejson2.properties with the proxy instructs the JWE JSON filter that a JWE JSON container for 2 recipients needs to be created, that the content encryption algorithm is A128GCM and key encryption algorithm is A128KW, and each recipient is using its own symmetric key encryption key. Each recipient specific entry will also include a 'kid' key identifier of the key encryption key for the service to figure out which JWE JSON entry is targeted at which recipient.

Setting up the client took you all one hour.

Next task was to prototype a service code. That was even easier. Loading the recipient specific properties, locating a recipient specific entry and getting the decrypted content was all what was needed.

Two hours in total. Note I did not promise it would take you 30 mins to do all the POC, it would've been really a child's play which is not realistic. With the two hours long project it is more complex, it felt like it was a walk in the park :-)



 

Friday, June 16, 2017

How to do JOSE in Apache CXF service code

This blog entry continues the series started with the introduction to Apache CXF JOSE implementation followed recently with the post talking about the signing of HTTP attachments.

So CXF helps with shipping JOSE filters which can protect the application data by wrapping them into JOSE JWS or JWE envelopes or verify that the data has been properly encrypted and/or signed. In these cases the application code is not even aware that the JOSE processors are involved.

How would one approach the task of signing/verifying and/or encrypting/decrypting the data directly in the application code ? For example, what if an individual property of the bigger payload needs to be JOSE protected ?

The most obvious approach is to use either CXF JOSE or the preferred 3rd party library to deal with the JOSE primitives in the application code. This is Option 1. It is a must option if one needs to have a closer control over the JOSE envelope creation process.

Or you can basically do nearly nothing at all and let CXF handle it for you, this is Option 2. This is a CXF Way Option - make it as easy as possible for the users to embrace the advanced technologies fast. It is not though only about making it easy - but is also about having a more flexible and even portable JOSE-aware code.

In this case such requirements as "sign only" or "encrypt only" or "sign and encrypt" and similarly for the "verify/decrypt" are not encoded in the code - it is managed at the time of configuring the JOSE helpers from the application contexts (by default they only sign/verify).

Likewise, the signature and encryption algorithm and key properties are controlled externally.

I know, it is hard to believe that it can be so easy. Try it to believe it. Enjoy !



Tuesday, May 23, 2017

Signing HTTP Attachments with Apache CXF JOSE

JOSE, the primary mechanism for securing various OAuth2/OIDC tokens, slowly but surely is becoming the main technology for securing the data in the wider contexts. JOSE, alongside COSE, will become more and more visible going forward.

I talked about Apache CXF JOSE implementation in this post. One of the practical aspects of this implementation is that one can apply JOSE to securing the regular HTTP payloads, with the best attempt at keeping the streaming going made by the sender side filters, with the JOSE protection of these payloads (JWS signature or JWE encryption) being able to 'stay' with the data even beyond the HTTP request-response time if needed.

In CXF 3.1.12 I have enhanced this feature to support the signing of HTTP attachments. It depends on JWS Detached Content and Unencoded Content features which allow to integrity-protect the payload which can continue flowing to its destination in a clear form.

Combining it with the super-flexible mechanism of processing the attachments in Apache CXF, and particularly with the newly introduced Multipart filters which let pre-process individual multipart attachment streams, helped produce the final solution.  

Besides, as part of this effort, the optional binding of the outer HTTP headers to the secure JWS or JWE payloads has also been realized.

Be the first in experimenting with this IMHO very cool feature, try it and provide the feedback, enjoy !


Thursday, May 18, 2017

Distributed Tracing with CXF: New Features

As you may already know Apache CXF has been offering a simple but effective support for tracing CXF client and server calls with HTrace since 2015.

What is interesting about this feature is that it was done after the DevMind attended to Apache Con NA 2015 and got inspired about integrating CXF with HTrace.

You'll be glad to know this feature has now been enhanced to get the trace details propagated to the logs which is the least intrusive way of working with HTrace though should you need more advanced control, CXF will help, see this section for example.

CXF has also been integrated with Brave. That should do better for CXF OSGI users. The integration work with Brave 4 is under way now.

Monday, December 19, 2016

[OT] You worked with CXF, Have a Great Time Out

Apache CXF has had a good year, with thanks to you using it, reporting the issues, asking the questions, with some of you spending a lot of your own time on helping improving it and keeping it flying and alive.

Time has come for a well deserved break. Have a Great Time Out, enjoy it !


Tuesday, November 29, 2016

Bean Validation for CXF JAX-RS Proxies

If you work with CXF JAX-RS Client proxies and have been thinking for a while, wouldn't it be good to have the proxy method parameters validated with the Bean Validation annotations, before the remote invocation is done, then a good news is, yes, starting from CXF 3.1.9 (which is due soon) it will be easy to do, have a look at this test please.

If you have the code which is considered to be safe with the respect to how it initializes the entities which will be posted to the remote targets then the client side bean validation might not be needed.

It can be more useful for the cases where the proxies are collecting the data from the databases or some other external sources - using the bean validation check to minimize the risk of posting some not well initialized data can indeed help.

I'd like to thank Johannes Fiala for encouraging us to have this feature implemented.