[jboss-cvs] JBossAS SVN: r66843 - in projects/security/security-docs/trunk/whitepapers/clusteredsso/en: modules and 1 other directory.
jboss-cvs-commits at lists.jboss.org
jboss-cvs-commits at lists.jboss.org
Wed Nov 7 18:50:11 EST 2007
Author: mmoyses
Date: 2007-11-07 18:50:11 -0500 (Wed, 07 Nov 2007)
New Revision: 66843
Modified:
projects/security/security-docs/trunk/whitepapers/clusteredsso/en/master.xml
projects/security/security-docs/trunk/whitepapers/clusteredsso/en/modules/clusteredSSO.xml
Log:
Updated ClusteredSSO document
Modified: projects/security/security-docs/trunk/whitepapers/clusteredsso/en/master.xml
===================================================================
--- projects/security/security-docs/trunk/whitepapers/clusteredsso/en/master.xml 2007-11-07 22:52:57 UTC (rev 66842)
+++ projects/security/security-docs/trunk/whitepapers/clusteredsso/en/master.xml 2007-11-07 23:50:11 UTC (rev 66843)
@@ -11,17 +11,29 @@
<releaseinfo>1.0</releaseinfo>
+ <authorgroup>
+
<author>
- <firstname>Shakthi</firstname>
+ <firstname>Marcus</firstname>
- <surname>Sambasivam</surname>
+ <surname>Moysés</surname>
- <affiliation>
- Jboss Support and Security Ambasiddor
- </affiliation>
+ <affiliation><jobtitle>JBoss Support Engineer</jobtitle></affiliation>
- <address>http://labs.jboss.com/portal/jbosssecurity/</address>
+ <email>mmoyses at redhat.com</email>
</author>
+
+ <author>
+ <firstname>Anil</firstname>
+
+ <surname>Sandhana</surname>
+
+ <affiliation><jobtitle>JBoss Security Project Lead</jobtitle></affiliation>
+
+ <email>anil.saldhana at jboss.com</email>
+
+ </author>
+ </authorgroup>
</bookinfo>
<toc></toc>
@@ -41,8 +53,6 @@
of information for secure operation of JBoss Products as well as
applications running on them.</para>
- <para>If you have questions, please feel free to contact the JBoss
- Security team at the afore mentioned URL.</para>
</preface>
&clusteredSSO;
Modified: projects/security/security-docs/trunk/whitepapers/clusteredsso/en/modules/clusteredSSO.xml
===================================================================
--- projects/security/security-docs/trunk/whitepapers/clusteredsso/en/modules/clusteredSSO.xml 2007-11-07 22:52:57 UTC (rev 66842)
+++ projects/security/security-docs/trunk/whitepapers/clusteredsso/en/modules/clusteredSSO.xml 2007-11-07 23:50:11 UTC (rev 66843)
@@ -3,36 +3,31 @@
<title>Clustered SingleSignOn</title>
<section>
- <title>Implementation of SSO</title>
+ <title>Introduction to SingleSignOn</title>
- <para>One of the ways to achieve SSO in web applications and containers is
- to pass the credentials as a part of HTTP cookie or part of URL through
- URL re-writing. When the browser sends subsequent request, it re-submits
- the information to establish the user identity. The down side of this is
- that the cookie information can be trapped and hacked. To make it fool
- proof, we can secure this using HTTPS connection. The other way is by
- keeping the user id information in the HTTP session.</para>
+ <para>Single Sign-On allows an user to authenticate to one application and
+ be recognized on all applications deployed in the same virtual host.</para>
</section>
<section>
- <title>JBoss Implementation Of ClusteredSingleSignOn Solution</title>
+ <title>JBoss implementation of Clustered SingleSignOn solution</title>
<para>JBoss web tier offers clustered SSO solution for web clients with the
- org.jboss.web.tomcat.tc5.sso.ClusteredSingleSignOn valve, which extends the
- standard Tomcat SSO valve. JBossCache is used for SSO credential caching
- and replication.</para>
+ <literal>org.jboss.web.tomcat.tc5.sso.ClusteredSingleSignOn</literal>
+ valve, which extends the standard Tomcat SSO valve. JBossCache is used for
+ SSO credential caching and replication.</para>
<itemizedlist>
<listitem>
- <para>This SSO solution will enable SSO failover across multiple
- nodes</para>
+ <para>The SSO solution will enable SSO failover across multiple
+ nodes.</para>
</listitem>
</itemizedlist>
<itemizedlist>
<listitem>
<para>It allows load balancer to direct request for different web apps
- to different clustered members while maintaining the SSO</para>
+ to different clustered members while maintaining the SSO.</para>
</listitem>
</itemizedlist>
@@ -73,12 +68,12 @@
<itemizedlist>
<listitem>
<para>A session timeout does not invalidate the SSO if other
- sessions are still valid</para>
+ sessions are still valid.</para>
</listitem>
</itemizedlist>
<section>
- <title>Configuration of ClusteredSingleSignOn for different JBoss
+ <title>Configuration of Clustered SingleSignOn for different JBoss
versions</title>
<para></para>
@@ -87,9 +82,10 @@
<listitem>
<para>For 3.2.4</para>
- <para>To enable ClusteredSingleSignOn in JBoss, in the
- jbossweb-tomcat5x.sar/server.xml file, inside the element of any
- virtual hosts for which you want single sign-on support, add an element:</para>
+ <para>To enable Clustered SingleSignOn in JBoss, in the
+ <literal>jbossweb-tomcat5x.sar/server.xml</literal> file, inside the
+ element of any virtual hosts for which you want single sign-on
+ support, add an element:</para>
<para><programlisting><Valve className="org.jboss.web.tomcat.tc5.sso.ClusteredSingleSignOn"
treeCacheName="jboss.cache:service=TomcatClusteringCache" debug="0"/></programlisting></para>
@@ -97,30 +93,32 @@
<para>If using ClusteredSingleSignOn valve, make sure the standard
single sign on valve is commented out.</para>
- <para>The ClusteredSingleSignOn valve depends on the existence of a
+ <para>The Clustered SingleSignOn valve depends on the existence of a
JBossCache MBean, which must be separately configured. This is done
by deploying a MBean as a service. Note that the value of the
- treeCacheName attribute of ClusteredSingleSignOn valve element in
- server.xml must match the JMX object name of the JBossCache
- MBean.</para>
+ treeCacheName attribute of Clustered SingleSignOn valve element in
+ <literal>server.xml</literal> must match the JMX object name of the
+ JBossCache MBean.</para>
</listitem>
<listitem>
<para>For 3.2.6/4.0</para>
<para>Beginning with JBoss-3.2.6 and 4.0 releases, the
- ClusteredSingleSignOn valve by default shares a JBossCache MBean with
- the clustered HTTP session replication service. So we don’t need to
- configure treeCacheName and a MBean service explicitly because
+ Clustered SingleSignOn valve by default shares a JBossCache MBean
+ with the clustered HTTP session replication service. So we don’t need
+ to configure treeCacheName and a MBean service explicitly because
it is already available as a standard JBoss Service. We just need to
- configure ClusteredSingleSignOn valve like this in server.xml file
- under jbossweb-tomcat5x.sar directory.</para>
+ configure Clustered SingleSignOn valve like this in
+ <literal>server.xml</literal> file under
+ <literal>jbossweb-tomcat5x.sar</literal> directory.</para>
<para><programlisting><Valve className="org.jboss.web.tomcat.tc5.sso.ClusteredSingleSignOn"
debug="0"/></programlisting></para>
<para>The default JBossCache MBean is described in the
- tc5-cluster-service.xml file in the deploy directory</para>
+ <literal>tc5-cluster-service.xml</literal> file in the deploy
+ directory.</para>
</listitem>
<listitem>
@@ -130,10 +128,12 @@
single hostname. It means SSO will work for same host names like
this:</para>
- <para>•http://www.xyz.com/app1 •http://www.xyz.com/app2</para>
+ <para>•<literal>http://www.xyz.com/app1</literal>
+ •<literal>http://www.xyz.com/app2</literal></para>
- <para>and SSO will not work if the host names is different
- •http://app1.xyz.com •http://app2.xyz.com </para>
+ <para>and SSO will not work if the host names are different:</para>
+ <para>•<literal>http://app1.xyz.com</literal>
+ •<literal>http://app2.xyz.com</literal></para>
<para>To address this issue, a new attribute called cookie domain in
the CSSO valve. The purpose of this attribute is to increase the
@@ -153,15 +153,30 @@
<itemizedlist>
<listitem>
- <para>BuddyReplication and ClusteredSSO</para>
+ <para>Only useful within a cluster of JBoss web servers; SSO does not
+ propagate to other resources.</para>
+ </listitem>
+ <listitem>
+ <para>Requires use of container managed authentication (via
+ <login-config> element in web.xml).</para>
+ </listitem>
+
+ <listitem>
+ <para>Requires Cookies. SSO is maintained via a cookie and URL
+ rewriting is not supported.</para>
+ </listitem>
+
+ <listitem>
+ <para>BuddyReplication and Clustered SingleSignOn</para>
+
<para>From Jboss 4.0.5 onwards JBossCache offers configuration option
called Buddy Replication, which means the cached data will not be
replicated across the entire cluster. Instead it will be replicated to
one or more buddy to ensure backup copies. Buddy Replication is much
more efficient, and it is perfect for cached HTTP sessions as it uses
session affinity which makes the load balancer send all requests for a
- session to the same server. However, with ClusteredSingleSignOn, the
+ session to the same server. However, with Clustered SingleSignOn, the
load balancer might link the user to different servers for the
different webapps being accessed. As a result, multiple servers in the
cluster need to monitor the cached data. For example, if the user logs
@@ -169,8 +184,8 @@
need to know that the SSO is invalidated. It is insufficient if only
the buddies are informed. If users want to enable buddy replication
for HTTP sessions, to over come the above limitation they would have
- to configure and deploy Separate JBossCache MBean for
- ClusteredSingleSignOn.</para>
+ to configure and deploy Separate JBossCache MBean for Clustered
+ SingleSignOn.</para>
</listitem>
<listitem>
@@ -183,42 +198,18 @@
server/default/lib directory and removing them from your WAR/EAR
files.</para>
</listitem>
-
- <listitem>
- <para>Mixing Authentication Schemes</para>
-
- <para>There are subtle differences between the manner SSO works and
- the standard Tomcat valve works in standalone Tomcat, in a situation
- where different webapps under the same virtual host use different
- authentication schemes. This is because JBoss requires each request
- from the user be re-authenticated; therefore when each request comes
- in, the SingleSignOn valve needs to have sufficient security
- information in its cache to re-authenticate the user. For example, if
- the user first access a webapp which uses Form or Basic authentication
- and then he/she access another web app associated with same Virtual
- host using Digest Authentication, the user will be prompted for login,
- because the cached username/password from the FORM/BASIC
- authentication will not be sufficient to do a digest authentication.
- Once he successfully authenticates using DIGEST, the browser
- automatically sends the information with each request, so that the
- user can switch between DIGEST and FORM/BASIC webapps thereafter
- without issue.</para>
- </listitem>
-
- <listitem>
- <para>Only useful within a cluster of JBoss web servers; SSO does not
- propagate to other resources.</para>
- </listitem>
-
- <listitem>
- <para>Requires use of container managed authentication (via
- <login-config> element in web.xml).</para>
- </listitem>
-
- <listitem>
- <para>Requires Cookies. SSO is maintained via a cookie and URL
- rewriting is not supported.</para>
- </listitem>
</itemizedlist>
</section>
+
+ <section>
+ <title>Resources</title>
+
+ <para><ulink url="http://wiki.jboss.org/wiki/Wiki.jsp?page=SingleSignOn">
+ JBoss Wiki</ulink></para>
+
+ <para>
+ <ulink url="http://docs.jboss.org/jbossas/jboss4guide/r3/html/ch9.chapt.html#d0e22429">
+ JBoss Documentation</ulink></para>
+
+ </section>
</chapter>
\ No newline at end of file
More information about the jboss-cvs-commits
mailing list