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>
