CXF Plugin (1.1)

The subproject Fediz purpose is to provide Single Sign On for Web Applications which is independent of an underlying Web Services framework like Apache CXF. The Fediz plugins for Tomcat, Jetty, etc. are independent of Apache CXF, whereas the Fediz IDP leverages the capabilities of the CXF STS to issue SAML tokens with Claims information to build applications which use Claims Based Authorization with all the benefits.

If the Fediz protected web application integrates with another application using Web Services you need to bundle a Web Services framework like Apache CXF with your web application. If it is required to support impersonation to call the Web Service, the security context of the application server must be delegated to the Web Services stack thus it can make the Web Service call on behalf of the browser user.

In release 1.1, the Fediz CXF plugin supports delegating the application server security context (SAML token) to the STS client of CXF. CXF is then able to request a security token for the target Web Service from the STS on behalf of the browser user. Prior to release 1.1, this Java code had to be developed by the application developer.

It is required that one of the other Fediz plugins are deployed to WS-Federation enable the application. After this step, the Fediz CXF plugin can be installed to integrate the Web SSO layer with the Web Services stack of Apache CXF.

Installation

It's recommended to use Maven to resolve the dependencies as illustrated in the the example wsclientWebapp.

    <dependency>
        <groupId>org.apache.cxf.fediz</groupId>
        <artifactId>fediz-cxf</artifactId>
        <version>1.1.0</version>
    </dependency>

The example contains a README with instructions for building and deployment.

Configuration

Two configurations are required in web.xml to enable the FederationFilter to cache the security context in the thread local storage and in the spring configuration file applicationContext.xml to configure a callback handler to provide the STS client the security context stored in the thread local storage.

    <filter>
        <filter-name>FederationFilter</filter-name>
        <filter-class>org.apache.cxf.fediz.core.servlet.FederationFilter</filter-class>
    </filter>

    <filter-mapping>
        <filter-name>FederationFilter</filter-name>
        <url-pattern>/secure/*</url-pattern>
    </filter-mapping>

The FederationFilter is part of the library fediz-core.

    <bean id="delegationCallbackHandler"
        class="org.apache.cxf.fediz.cxf.web.ThreadLocalCallbackHandler" />

    <jaxws:client id="HelloServiceClient" serviceName="svc:GreeterService"
        ...
        wsdlLocation="WEB-INF/wsdl/hello_world.wsdl">
        <jaxws:properties>
            <entry key="ws-security.sts.client">
                <bean class="org.apache.cxf.ws.security.trust.STSClient">
                    ...
                    <property name="onBehalfOf" ref="delegationCallbackHandler" />
                    ...
                 </bean>
            </entry>
            <entry key="ws-security.cache.issued.token.in.endpoint" value="false" />
        </jaxws:properties>
    </jaxws:client>

The ThreadLocalCallbackHandler is part of the library fediz-cxf.

If you have set the property ws-security.cache.issued.token.in.endpoint to false, CXF will cache the issued token per security context dependent on the returned lifetime element of the STS. When the cached token for the target web services is expired, CXF will request a new token from the STS on-behalf-of the cached Fediz security context.

There is no special Java code required to get this functionality as illustrated in the following code snippet:

    Greeter service = (Greeter)ApplicationContextProvider.getContext().getBean("HelloServiceClient");
    String reply = service.greetMe();