Return-Path: X-Original-To: apmail-cxf-commits-archive@www.apache.org Delivered-To: apmail-cxf-commits-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id E0B8CDA83 for ; Mon, 9 Jul 2012 09:48:17 +0000 (UTC) Received: (qmail 38011 invoked by uid 500); 9 Jul 2012 09:48:17 -0000 Delivered-To: apmail-cxf-commits-archive@cxf.apache.org Received: (qmail 37890 invoked by uid 500); 9 Jul 2012 09:48:17 -0000 Mailing-List: contact commits-help@cxf.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cxf.apache.org Delivered-To: mailing list commits@cxf.apache.org Received: (qmail 37863 invoked by uid 99); 9 Jul 2012 09:48:16 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 09 Jul 2012 09:48:16 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=5.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.4] (HELO eris.apache.org) (140.211.11.4) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 09 Jul 2012 09:48:12 +0000 Received: from eris.apache.org (localhost [127.0.0.1]) by eris.apache.org (Postfix) with ESMTP id 6F46B2388847 for ; Mon, 9 Jul 2012 09:47:51 +0000 (UTC) Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: svn commit: r825115 - in /websites/production/cxf/content: cache/docs.pageCache docs/saml-web-sso.html Date: Mon, 09 Jul 2012 09:47:51 -0000 To: commits@cxf.apache.org From: buildbot@apache.org X-Mailer: svnmailer-1.0.8-patched Message-Id: <20120709094751.6F46B2388847@eris.apache.org> Author: buildbot Date: Mon Jul 9 09:47:50 2012 New Revision: 825115 Log: Production update by buildbot for cxf Modified: websites/production/cxf/content/cache/docs.pageCache websites/production/cxf/content/docs/saml-web-sso.html Modified: websites/production/cxf/content/cache/docs.pageCache ============================================================================== Binary files - no diff available. Modified: websites/production/cxf/content/docs/saml-web-sso.html ============================================================================== --- websites/production/cxf/content/docs/saml-web-sso.html (original) +++ websites/production/cxf/content/docs/saml-web-sso.html Mon Jul 9 09:47:50 2012 @@ -125,7 +125,7 @@ Apache CXF -- SAML Web SSO +

Introduction

@@ -433,7 +433,92 @@ the current user, persists it and redire

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

-

CXF ships an EhCache-based implementation. Users can register their own custom implementations if required.

+

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 configuration can be used to change it:

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

+ +

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.

+ +

For example, assume you have server1, server2 and server3 which all support a bigger application. One can have a serverRacs web application which will host a RACS endpoint. Next, server1, server2 and server3 SSO filters will all point to this standalone RACS endpoint when redirecting the user to IDP and IDP will eventually redirect the user to RACS which in turn will redirect the user to the original targer URI supported by server or server2 or server3.

+ +

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.

+ +

For example, the following jaxrs:endpoint can be deployed alongside the RACS endpoint running in its own web application:

+
+
+    <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">
+        <property name="stateProvider" ref="stateManager"/>
+        <property name="signaturePropertiesFile" value="serviceKeystore.properties"/>
+        <property name="callbackHandlerClass" value="oauth2.sso.SSOCallbackHandler"/>
+    </bean>
+    
+    <jaxrs:server address="/"> 
+       <jaxrs:serviceBeans>
+          <ref bean="consumerService"/>
+          <ref bean="stateManager"/> 
+       </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"
+         address="https://localhost:${racs.port}/racs"
+         serviceClass="org.apache.cxf.rs.security.saml.sso.state.HTTPSPStateManager"/>
+         
+ <bean id="ssoRedirectURI" class="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.

+ +

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.