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.
(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.
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.
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 :
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 :
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.
 Project Repository