cxf-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From build...@apache.org
Subject svn commit: r825243 - in /websites/production/cxf/content: cache/docs.pageCache docs/saml-web-sso.html
Date Tue, 10 Jul 2012 12:47:49 GMT
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>



Mime
View raw message