Apache CXF, MSF4J, WebServices, WSO2 Identity Server

Using Apache CXF Security Token Service with MSF4J Transport


I’m writing this post to share my experience on Using Apache CXF library with the WSO2 MSF4J framework. My goal was to Implement a component which can bridge the gap between MSF4J and CXF Security Token Service. In simply I had to decouple CXF implementation of STS and Security Policy Enforcement (WS-SecurityPolicy) from CXF transport and couple it with MSF4J to mimic the behaviour of a Web Services engine.

Most challenging part of the project was to decouple CXF WS-* implementations from CXF transport. Therefore I had to do some research on Apache CXF beforehand. I’ll explain what I learnt by doing so here onwards.

Apache CXF Security Token Service

WS-Trust extends the WS-Security specification to allow issuing, renewing, and validation of security tokens. A lot of what WS-Trust does centers around the use of a “Security Token Service”, or STS. The STS is contacted to obtain security tokens that are used to create messages to talk to the services. The primary use of the STS is to acquire SAML tokens used to talk to the service.

Apache CXF provides an implementation of STS which is the heart of WS-Trust specification. It supports WS-Trust 1.3 specification as well as some of the features of WS-Trust 1.4 specification.


MSF4J is a lightweight, high-performance framework for building microservices in Java. It provides a cool rest framework which provides most of the functionalities provided by JAX-RS. Github repo can be found here.

Architectural Overview


(01) The user makes a SOAP call to Security Token Service Endpoint in order to get a          SAML 2.0 token

This is an ordinary SOAP call which has MIME headers as well as a SOAP body and a SOAP header enclosed within a SOAP envelope.

(02) MSF4J captures the SOAP call as an HTTP message and extracts the HTTP body which is the SOAP envelope.

(03) Captured SOAP Message is then converted into a CXF Message object which can be consumed by any CXF interceptor.

Since the MSF4J endpoint needs to be secured by WS-Security Policy I needed to verify if SOAP security header contains valid security details. Therefore I needed to implement a layer above the MSF4J endpoint. In that case, I used an Interceptor to process SOAP security header for user information (Username token, Signature, Kerberos token etc.) verification.

(04) If User information is valid then Request is delegated to the MSF4J STS Endpoint

(05) MSF4J Endpoint create an Endpoint to Apache CXF Security Token Service Provider and get a SAML 2.0 token

(06) SAML 2.0 Token is then embedded within a SOAP envelope and send as the response t the user.

Class Organisation

Class Diagram.jpg

Security Policy Enforcement

As I explained earlier in this post, decoupling CXF WS-Security Policy implementation from CXF transport and coupling with MSF4J was the most challenging part of this project.

Step 01

Before being processed and verified by CXF I needed to build an Apache Neethi Object by parsing XML Policy document.

Sample Security Policy for UsernameToken :


Step 02

Then CXF PolicyInInterceptor can be used to get all Interceptors required to process the SOAP security header and verify securityDetails.

eg. Interceptors Needed to verify UsernameToken security :

  1. WSS4JPolicyBasedStaxInInterceptor
  2. WSS4JStaxInInterceptor
  3. UsrnameTokenInterceptor
  4. PolicyVerificationInterceptor

WSDL Builder

Since we are not using a Web Services engine, WSDL doesn’t play a much significant role in this scenario. It is useful only when a client needs to get service definition of the STS.

But as I mentioned earlier CXF implementation of WS-Security Policy is tightly coupled with CXF transport. Therefore when processing security policies most of the CXF Interceptors require Components of WSDL. Because of that, I had to use WSDLDefinitionBuilder to parse the WSDL XML file and set relevant extensions of previously created CXF Message Object which is then used by the STS engine as well as CXF Interceptors.


[01] WS-Security Policy Specification

[02] WS-Trust Specification

[03] Project Repository

[04] Developer Documentation


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s