...

Introduction

...

• String issuerId - it defaults to the base URI of the application endpoint protected by this filter, for example, "http://localhost:8080/services/app1".
• AuthnRequestBuilder authnRequestBuilder - A builder that constructs the SAML Request. It defaults to DefaultAuthnRequestBuilder.

The IDP address is where filters will redirect users to and the RACS address is where users will be redirected by IDP to.
RACS will set up a security context and redirect the user back to the original application address by using the RelayState token which is included by the filters when users are initially redirected to IDP.

...

What is actually different in this case from the GET-based redirect is that the filter prepares an instance of SAMLRequestInfo which is subsequently bound to an XHTML view via a JSP filter. The view will typically have a Java Script handler which will actually redirect the user to IDP when it is loaded into the browser. The data to view binding is facilitated by org.apache.cxf.jaxrs.provider.RequestDispatcherProvider, please see this page for more information.

...

The following properties affect the way filters manage the SSO state:

• SPStateManager stateProvider
• long stateTimeToLive - default is 2 minutes (in milliseconds).
• String webAppDomain.
• boolean addWebAppContext - default is true.
• boolean boolean addEndpointAddressToContext - default is false.

...

The RACS processes the SAML Response, and validates it in a number of ways:

• The SAMLProtocolResponseValidator validates the Response against the specifications and checks the signature of the Response (if it exists), as well as doing the same for any child Assertion of the Response. It validates the status code of the Response as well.
• The SAMLSSOResponseValidator validates the Response according to the Web SSO profile.

...

• boolean enforceKnownIssuer - Whether the Issuer of the Response (and child Assertions) is "known" to the RACS. This value is compared against the IDP URL configured on the filter. The default value is true.
• TokenReplayCache replayCache - A TokenReplayCache implementation to store Assertion IDs for the POST binding to guard against replay attacks. The default uses an implementation based on EhCache.

...

SP Security Filters and RACS depend on the custom SPStateManager implementation for persisting the current request and security context state.

CXF ships a basic MemorySPStateProvider and an EhCache-based implementation which is memory based with an option to overflow to the disk. Users can customize the EhCache provider or register their own custom SPStateProvider implementations if required.

...

<ehcache xsi:noNamespaceSchemaLocation="ehcache.xsd" updateCheck="false" monitoring="autodetect" dynamicConfig="true">

    <diskStore path="/home/username/work/ehcache"/>

    <defaultCache
            maxEntriesLocalHeap="5000"
            timeToIdleSeconds="3600"
            timeToLiveSeconds="3600"
            overflowToDisk="true"
            maxElementsOnDisk="10000000"
            diskPersistent="true"
            diskExpiryThreadIntervalSeconds="120"
            memoryStoreEvictionPolicy="LRU"
            />
</ehcache>

Assuming

...

this

...

configuration

...

is

...

saved

...

in

...

WEB-INF/ehcache.xml,

...

the

...

EhCache

...

provider

...

can

...

be

...

configured

...

as

...

follows:

{code:xml}
<bean id="stateManager" class="org.apache.cxf.rs.security.saml.sso.state.EHCacheSPStateManager">
    <constructor-arg value="/WEB-INF/ehcache.xml"/>
</bean>

Distributed State Management

...

In this case, one has to decide how the state between SSO security filters protecting the individual servers and RACS will be shared.
One approach is to setup the Ehcache provider to use Terracotta or RMI with the multicast or implement the alternative approach not involving Ehcache at all.

CXF offers a simple HTTPSPStateManager provider which can be used to simplify the task of setting up the distributed state cache, which can be used for simple distributed web applications or to support the more advanced applications at the proof-of-concept stage.

...

The alternative to having a distributed state cache be set up is to simply have a RACS endpoint collocated with every individual web application constituting the bigger application, see the earlier section describing SSO filters on how this can be easily set up. One possible downside of it is that there will be no centralized store managing the state required by different filters and RACS which in turn can make it more difficult to audit and log all the SSO-related activities spanning across all the bigger application.

Logout Service

CXF 3.0.0 introduces LogoutService. It will remove the SSO state for the logged-in user, and can be registered as an independent endpoint or service bean.

...

For example, one can imagine a user getting HTML page confirming the logout has been successful and linking to the application front page.

Metadata Service

...

A new MetadataService is available in CXF 3.1.0 and 3.0.5, which can publish SAML SSO Metadata for a given service. Similar to the Logout Service, it is registered as an independent endpoint or service bean. A sample spring configuration is available here in the CXF system tests.