[jboss-cvs] JBossAS SVN: r66793 - 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
Tue Nov 6 12:02:00 EST 2007
Author: mmoyses
Date: 2007-11-06 12:02:00 -0500 (Tue, 06 Nov 2007)
New Revision: 66793
Modified:
projects/security/security-docs/trunk/whitepapers/clusteredsso/
projects/security/security-docs/trunk/whitepapers/clusteredsso/en/modules/clusteredSSO.xml
Log:
Updated ClusteredSSO document
Property changes on: projects/security/security-docs/trunk/whitepapers/clusteredsso
___________________________________________________________________
Name: svn:ignore
+ build
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-06 16:18:40 UTC (rev 66792)
+++ projects/security/security-docs/trunk/whitepapers/clusteredsso/en/modules/clusteredSSO.xml 2007-11-06 17:02:00 UTC (rev 66793)
@@ -11,16 +11,16 @@
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>
+ keeping the user id information in the HTTP session.</para>
</section>
<section>
<title>JBoss Implementation Of ClusteredSingleSignOn Solution</title>
- <para>JBoss web tier offers clustered SSO solution for web clients by
- extending standard Tomcat valve to clustered SSO valve. JBOSS cache is
- used as an undercover to cache and replicate the user identity
- information. </para>
+ <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>
<itemizedlist>
<listitem>
@@ -32,61 +32,50 @@
<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>
+
+ <itemizedlist>
+ <listitem>
+ <para>The user will not be challenged as long as he accesses only
+ unprotected resources in any of the web applications on this virtual
+ host.</para>
+ </listitem>
+ </itemizedlist>
+
+ <itemizedlist>
+ <listitem>
+ <para>To access a protected resource in any web app, the user will
+ be challenged to authenticate using the login method defined for the
+ web app.</para>
+ </listitem>
+ </itemizedlist>
+
+ <itemizedlist>
+ <listitem>
+ <para>Once authenticated, the roles associated with this user will
+ be utilized for access control decisions across all of the
+ associated web applications, without challenging the user to
+ authenticate them to each application individually.</para>
+ </listitem>
+ </itemizedlist>
+
+ <itemizedlist>
+ <listitem>
+ <para>If the user logs out of one web application (for example, by
+ invalidating the corresponding session if form based login is used),
+ the user's sessions in all web applications will be
+ invalidated.</para>
+ </listitem>
+ </itemizedlist>
- <section>
- <title>SSO Rules for JBoss implementation </title>
-
<itemizedlist>
<listitem>
- <para> All web applications configured for this virtual host must
- share the same Realm.</para>
-
- <orderedlist>
- <listitem>
- <para>You can nest the Realm element inside this Host element
- (or the surrounding Engine element), but not inside a Context
- element for one of the involved web applications.</para>
- </listitem>
- </orderedlist>
- </listitem>
- </itemizedlist>
-
- <itemizedlist>
- <listitem>
- <para>To access a protected resource in any web app, the user will
- be challenged to authenticate using the login method defined for the
- web app.</para>
- </listitem>
- </itemizedlist>
-
- <itemizedlist>
- <listitem>
- <para>Once authenticated, the roles associated with this user will
- be utilized for access control decisions across all of the
- associated web applications, without challenging the user to
- authenticate them to each application individually.</para>
- </listitem>
- </itemizedlist>
-
- <itemizedlist>
- <listitem>
- <para>The user logs out of one web application (for example, by
- invalidating the corresponding session if form based login is used),
- the user's sessions in all web applications will be
- invalidated.</para>
- </listitem>
- </itemizedlist>
-
- <itemizedlist>
- <listitem>
<para>A session timeout does not invalidate the SSO if other
sessions are still valid</para>
</listitem>
</itemizedlist>
- </section>
<section>
<title>Configuration of ClusteredSingleSignOn for different JBoss
@@ -96,23 +85,46 @@
<orderedlist>
<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><programlisting><Valve className="org.jboss.web.tomcat.tc5.sso.ClusteredSingleSignOn"
+ treeCacheName="jboss.cache:service=TomcatClusteringCache" debug="0"/></programlisting></para>
+
+ <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
+ 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>
+ </listitem>
+
+ <listitem>
<para>For 3.2.6/4.0</para>
- <para>Beginning with JBoss-3.2.6 and 4.0 releases, the Clustered
- Single Sign On valve by default shares a JBossCache MBean with the
- clustered Http Session replication service. So we don’t need to
- configure TreeCacheName and tc5-cluster-service explicitly because
- it is already available as standard JBoss Service. We just need to
+ <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
+ 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>
+ under jbossweb-tomcat5x.sar directory.</para>
<para><programlisting><Valve className="org.jboss.web.tomcat.tc5.sso.ClusteredSingleSignOn"
- debug="0"/>
-</programlisting></para>
+ debug="0"/></programlisting></para>
+
+ <para>The default JBossCache MBean is described in the
+ tc5-cluster-service.xml file in the deploy directory</para>
</listitem>
<listitem>
- <para>For 4.0.4 </para>
+ <para>For 4.0.4</para>
<para>Prior to release 4.0.4.CR2, the SSO cookie is scoped to a
single hostname. It means SSO will work for same host names like
@@ -123,15 +135,14 @@
<para>and SSO will not work if the host names is different
•http://app1.xyz.com •http://app2.xyz.com </para>
- <para>To address this issue, we added a new attribute called cookie
- domain in the CSSO valve. The purpose of this attribute is to
- increase the scope of the SSO cookie from default ‘/’ domain to much
- broader domain. For example, for the above case to support SSO, we
- can configure like this: </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
+ scope of the SSO cookie from default ‘/’ domain to much broader
+ domain. For example, for the above case to support SSO, we can
+ configure like this:</para>
<para><programlisting><Valve className="org.jboss.web.tomcat.tc5.sso.ClusteredSingleSignOn"
- cookieDomain="xyz.com"/>
-</programlisting></para>
+ cookieDomain="xyz.com"/></programlisting></para>
</listitem>
</orderedlist>
</section>
@@ -144,7 +155,7 @@
<listitem>
<para>BuddyReplication and ClusteredSSO</para>
- <para>From Jboss 4.0.5 onwards JBoss Cache offers configuration option
+ <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
@@ -158,8 +169,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 JBoss Cache MBean for
- ClusteredSingleSignOn. </para>
+ to configure and deploy Separate JBossCache MBean for
+ ClusteredSingleSignOn.</para>
</listitem>
<listitem>
@@ -191,22 +202,22 @@
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>
+ without issue.</para>
</listitem>
<listitem>
<para>Only useful within a cluster of JBoss web servers; SSO does not
- propagate to other resources. </para>
+ propagate to other resources.</para>
</listitem>
<listitem>
<para>Requires use of container managed authentication (via
- <login-config> element in web.xml) </para>
+ <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>
+ rewriting is not supported.</para>
</listitem>
</itemizedlist>
</section>
More information about the jboss-cvs-commits
mailing list