Version 5
Created by asoldano on Feb 9, 2012 5:39 PM. Last modified by asoldano on Feb 9, 2012 6:48 PM.

    Here is an intro to testing that's currently in progress on the Apache CXF WS-trust functionalities usable on JBoss AS 7 through JBossWS-CXF integration.

     

    Apache CXF comes with WS-Trust 1.4 support. Starting from 2.5 version it also includes a full SecurityTokenService implementation.

    The WS-Trust implementation is completely integrated with the WS-SecurityPolicy.

     

    Apache CXF STS demo

    I've ported the sts demo that's part of the Apache CXF distribution starting from 2.5 version. The demo shows how to use the  SecurityTokenService (STS) implementation in Apache CXF. Here is an excerpt of the demo's readme:

     

    The policy of the service provider, [...], requires a SAML 2.0 token issued by an STS. The client will authenticate itself to the STS using a UsernameToken over the symmetric binding, and the STS will issue it the desired SAML 2.0 token, which the client then forwards to the service provider. As the IssuedToken is defined as the InitiatorToken of the Asymmetric binding in the policy of the service provider, the client will use the associated secret key to sign various parts of the message.

     

    JBossWS-CXF testcase

    The CXF demo has been ported to a JBossWS-CXF testsuite testcase, currently on the wstrust branch. The JBossWS-CXF integration has been moved to Apache CXF 2.5.2 as the STS service is available starting from CXF 2.5. The required dependency to OpenSAML has been added to the JBossWS-CXF project, whose build also creates an org.opensaml module when deploying the stack on the current JBoss AS 7.1 master.

    The sources for the WS-Trust testcase are available at:

    After checking out,  building and deploying to AS 7.1 the stack from the wstrust branch, the testcase can be run as follows:

    mvn -Pjboss710 -Djboss710.home=<path-to-jboss-710> -Dtest=WSTrustTestCase integration-test

     

    The testcase creates a custom security domain on JBoss AS 7.1 to be used by the STS application for authenticating the clients. Then it deploys 2 archives:

    jaxws-samples-wsse-policy-trust-sts.war

    The STS application deployment; the archive includes a sample WebServiceProvider endpoint extending the Apache CXF SecurityTokenServiceProvider. The published wsdl contract is the usual WS-Trust 1.4 STS wsdl  enriched by a policy for enforcing WS-Security communication (X509 signature / encryption with UsernameToken as supporting token for authentication). The endpoint constructor programmatically sets the SecurityTokenService components (for instance, it adds the SAMLTokenProvider and SAMLTokenValidator). The endpoint is annotated with @InInterceptors CXF annotation to add the org.jboss.wsf.stack.cxf.security.authentication.SubjectCreatingPolicyInterceptor interceptor for performing authentication against the JBoss AS security layer.

    The usual WSS4J Merlin configuration property file as well as the referenced keystore are also included in the archive.

    jaxws-samples-wsse-policy-trust.war

    A basic WS-SecurityPolicy enabled, contract-first JAXWS endpoint; the provided WSDL declares a policy for using WS-Security signature and encryption with an asymmetric binding whose initiator token has to be a SAML 2.0 assertion token.

    The usual WSS4J Merlin configuration property file as well as the referenced keystore are also included in the archive.

     

    The client

    The WSTrustTestCase declares a JAXWS client, whose RequestContext is enriched with both the usual Apache CXF WS-Security properties (Merlin props, username, etc.) and a STSClient instance. That is configured with the information on the STS wsdl URL as well as the WS-Security configuration properties for properly communicating with the STS.

     

    The testcase then triggers the following process:

    1. the client get the service endpoint WSDL; the Apache CXF engine parses it, processes the included policy and decides to contact the STS
    2. the STS client injected into the application client gets the STS wsdl; the Apache CXF engine processes the policy in it
    3. a WS-Security enabled communication (as per STS advertised policy) is established and the client issue a request for getting a SAML assertion token from the STS
    4. the STS endpoint receives the request, extracts the client identify from it and authenticates the client against the previously created AS security domain through the SubjectCreatingPolicyInterceptor
    5. the SAML token is returned to the client, which uses it for establishing a new connection with the service endpoint; the Apache CXF engine again setups signature/encryption as per endpoint advertised policy
    6. the service receives the token provided through the STS and performs the required invocation