Glen Mazza's Weblog

https://glenmazza.net/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.

Posted by Glen Mazza in Web Services at 07:00AM Apr 23, 2017 | Comments[0]

Post a Comment:

Calendar
« April 2023
Sun Mon Tue Wed Thu Fri Sat
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
Today
About Me
Java Software Engineer
TightBlog project maintainer
Arlington, Virginia USA
glen.mazza at pm dot me
GitHub profile for Glen Mazza at Stack Overflow, Q&A for professional and enthusiast programmers
Blog Search


Blog article index
Navigation
About Blog
Blog software: TightBlog 3.7.2
Application Server: Tomcat
Database: MySQL
Hosted on: Linode
SSL Certificate: Let's Encrypt
Installation Instructions