Glen Mazza's Weblog

« Deploying and Using... | Main | Using JUnit to test... »

https://web-gmazza.rhcloud.com/blog/date/20170423 Sunday April 23, 2017

Using Message-Layer Encryption to protect UsernameToken credentials

My previous blog entry on the UsernameToken profile for Apache CXF involved using transport-layer encryption (i.e., SSL) to encrypt the UsernameToken credentials. Message-layer encryption over a non-SSL transport can also be used, with two Symmetric Binding policy options:

  1. UsernameToken Authentication with Symmetric Key - as summarized here, the client generates a temporary secret key and confidentially transports it to the service by encrypting it with the server's public key. Communication between the client and service then rely on that secret key. This method probably provides the most natural conversion from transport-layer to message-layer encryption where it is still desired to use UsernameToken credentials for authentication.

    The below shows a WS-Policy block for this method:

  2. UsernameToken Authentication with Password Derived Key - This method is defined in the Key Derivation section of the UsernameToken Profile specification and further described in Colm's blog entry (with numerous examples). Here, an algorithm involving the UsernameToken password is used to generate the secret key for communication, possible because both the client and service know the password. No X.509 keys are used, and the UsernameToken name, along with new Salt and Iteration values but not the password are sent to the service.

    The below shows a WS-Policy block for this method:

    This solution appears to be less secure than the first one because an examination of the SOAP requests for these types of calls, at least with my configuration, is showing that the username token and salt values are going out in cleartext (not encrypted). I did not see this problem occurring with the symmetric key technique.

    For the password-derived key method, there is also the option of using derived keys based on the password-derived key by adding the <sp:RequireDerivedKeys/> element in the WSDL policy (presently commented-out in the WSDL provided with the sample.) Derived keys are recommended at least with WS-SecureConversation but I am unaware of any recommendations of them with respect to password-derived keys.

I created a sample project, cxf_ut_messagelayer that demonstrate both of the above cases. It can be obtained from GitHub by using either the download ZIP button or git clone -v git://github.com/gmazza/blog-samples.git command. (Of course don't use any supplied sample keys in production work.) The sample is configured to use the first technique by default but can be switched easily to the second method by commenting and uncommenting relevant portions in the following files of the project: client/../cxf.xml, service/../DoubleIt.wsdl, and war/../cxf-servlet.xml.

The sample runs on either standalone or embedded Tomcat in the same fashion as the other web service tutorials on this blog, with the SOAP client activated as usual via mvn exec:exec from the client submodule folder.

Comments:

Post a Comment:
  • HTML Syntax: NOT allowed

Valid HTML! Valid CSS!

This is a personal weblog, I do not speak for my employer.