...

...

...

...

...

...

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 'stateProvider' refers to a custom SPStateManager implementation and is used for filters and RACS coordinating with the filters persisting the current user request state, RACS validating it and persisting the current security context state and filters getting the information about the context. Filters and RACS use a 'RelayState' token to work with the current request state. RACS persists the security context and the filters retrieve and validate it using the cookie which RACS also sets to point to this security context.

...

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.

...

Setting a "keyInfoMustBeAvailable" property to false will lead to a default store alias being used to load the certificate for validating the signature.

SSO State Provider

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

Using RACS as Endpoint Filter

As you can see from the documentation above, RACS is typically represented as an independent service endpoint or service bean: in such cases RACS redirects the requestor back to the the actual endpoint.

Starting from CXF 3.0.0 it is possible to set it up as the target endpoint filter, simply add org.apache.cxf.rs.security.saml.sso.RequestionAssertionConsumerFilter to the list of other endpoint providers.

In this case the authentication filters do not have to set their "assertionConsumerServiceAddress" property

SSO State Provider

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 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.

For example, by default, the EhCache provider will overflow the data to the system temp directory and will not persist the data across restarts. The following EhCache default configuration can be used to change itseen here. To change the default configuration, simply copy this file to a custom location and make whatever changes are required. Assuming this configuration is saved in WEB-INF/ehcache.xml, the EhCache provider can be configured as follows:

<ehcache xsi:noNamespaceSchemaLocation="ehcache.xsd" updateCheck="false" monitoring="autodetect" dynamicConfig="true">
<bean id="stateManager" class="org.apache.cxf.rs.security.saml.sso.state.EHCacheSPStateManager">
    <diskStore<constructor-arg pathvalue="/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

WEB-INF/ehcache.xml"/>
</bean>

Distributed State Management

If you have a complex application supported by a number of wars deployed If you have a complex application supported by a number of wars deployed into different containers, one has to decide whether to have a single RequestAssertionConsumerService (RACS) endpoint which IDP will redirect to when processing the user authentication requests or have a separate RACS endpoint per every web application which all form a bigger application.

...

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.

...

    <bean id="stateManager" class="org.apache.cxf.rs.security.saml.sso.state.HTTPSPStateManager"/>

    <bean id="consumerService" class="org.apache.cxf.rs.security.saml.sso.RequestAssertionConsumerService".RequestAssertionConsumerService">
        <property name="stateProvider" ref="stateManager"/>
        <property name="signaturePropertiesFile" value="serviceKeystore.properties"/>
        <property name="stateProvidercallbackHandlerClass" refvalue="stateManageroauth2.sso.SSOCallbackHandler"/>
    </bean>
    
  <property name  <jaxrs:server address="signaturePropertiesFile" value="serviceKeystore.properties/"> 
       <jaxrs:serviceBeans>
          <ref bean="consumerService"/>
        <property name="callbackHandlerClass" value="oauth2.sso.SSOCallbackHandler  <ref bean="stateManager"/> 
       </bean>jaxrs:serviceBeans>
    
    <jaxrs:server address="/"> </jaxrs:server>

Note that the RACS bean itself directly uses HTTPSPStateManager which is also available as an HTTP endpoint for all the SSO security filters to work with.
Here is an example of how the SPStateManagers at the individual SSO filter end can use this HTTP endpoint:

<jaxrs:client id="stateManager"
       <jaxrs:serviceBeans>
          <ref bean="consumerService"/>address="https://localhost:${racs.port}/racs"
          <ref bean="stateManagerserviceClass="org.apache.cxf.rs.security.saml.sso.state.HTTPSPStateManager"/> 
       </jaxrs:serviceBeans>
     </jaxrs:server>

Note that the RACS bean itself directly uses HTTPSPStateManager which is also available as an HTTP endpoint for all the SSO security filters to work with.
Here is an example of how the SPStateManagers at the individual SSO filter end can use this HTTP endpoint:

<jaxrs:client id="stateManager"
 <bean id="ssoRedirectURI" class="org.apache.cxf.rs.security.saml.sso.SamlRedirectBindingFilter">
    <property     address="https://localhost:${racs.port}/racs"name="idpServiceAddress" value="${idp.address}"/>
    <property name="assertionConsumerServiceAddress" 
         serviceClass="org.apache.cxf.rs.security.saml.sso.state.HTTPSPStateManager      value="https://localhost:${racs.port}/racs/sso"/>
    <property name="stateProvider" ref="stateManager"/>
   
 <bean<property idname="ssoRedirectURIaddWebAppContext" classvalue="org.apache.cxf.rs.security.saml.sso.SamlRedirectBindingFilter">
    <property name="idpServiceAddress" value="${idp.address}"/>
    <property name="assertionConsumerServiceAddress" 
               value="https://localhost:${racs.port}/racs/sso"/>
    <property name="stateProvider" ref="stateManager"/>
    <property name="addWebAppContext" value="false"/> 
 </bean>

Note that a JAX-RS Client proxy to the HTTPSPStateManager endpoint is used as SPStateManager reference.

"false"/> 
 </bean>

Note that a JAX-RS Client proxy to the HTTPSPStateManager endpoint is used as SPStateManager reference.

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.

It returns LogoutResponse bean which is expected to be processed by the View handler.

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 testsThe 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.