svn commit: r825243 - in /websites/production/cxf/content: cache/docs.pageCache docs/saml-web-sso.html

[bu...@apache.org]

Author: buildbot
Date: Tue Jul 10 12:47:48 2012
New Revision: 825243

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 Tue Jul 10 12:47:48 2012
@@ -467,7 +467,7 @@ Assuming this configuration is saved in 
 
 <p>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.</p>
 
-<p>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.</p>
+<p>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 target URI supported by server or server2 or server3.</p>
 
 <p>In this case, one has to decide how the state between SSO security filters protecting the individual servers and RACS will be shared.<br clear="none">
 One approach is to setup the Ehcache provider to use <a shape="rect" class="external-link" href="http://ehcache.org/documentation/configuration/distributed-cache-configuration" rel="nofollow">Terracotta or RMI with the multicast</a> or implement the alternative approach not involving Ehcache at all.</p>