[jboss-cvs] JBossAS SVN: r63445 - projects/security/security-docs/trunk/whitepapers/clusteredsso/en/modules.
jboss-cvs-commits at lists.jboss.org
jboss-cvs-commits at lists.jboss.org
Mon Jun 11 03:38:47 EDT 2007
Author: ssambasivam at jboss.com
Date: 2007-06-11 03:38:47 -0400 (Mon, 11 Jun 2007)
New Revision: 63445
Added:
projects/security/security-docs/trunk/whitepapers/clusteredsso/en/modules/clusteredSSO.xml
Log:
Commiting for Clustered SSO
Added: projects/security/security-docs/trunk/whitepapers/clusteredsso/en/modules/clusteredSSO.xml
===================================================================
--- projects/security/security-docs/trunk/whitepapers/clusteredsso/en/modules/clusteredSSO.xml (rev 0)
+++ projects/security/security-docs/trunk/whitepapers/clusteredsso/en/modules/clusteredSSO.xml 2007-06-11 07:38:47 UTC (rev 63445)
@@ -0,0 +1,213 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<chapter id="howto">
+ <title>Clustered SingleSignOn</title>
+
+ <section>
+ <title>Implementation of SSO</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>
+ </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>
+
+ <itemizedlist>
+ <listitem>
+ <para>This 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>
+ </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
+ versions</title>
+
+ <para></para>
+
+ <orderedlist>
+ <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
+ configure ClusteredSingleSignOn valve like this in server.xml file
+ under jbossweb-tomcat5x.sar directory. </para>
+
+ <para><programlisting><Valve className="org.jboss.web.tomcat.tc5.sso.ClusteredSingleSignOn"
+ debug="0"/>
+</programlisting></para>
+ </listitem>
+
+ <listitem>
+ <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
+ this:</para>
+
+ <para>•http://www.xyz.com/app1 •http://www.xyz.com/app2</para>
+
+ <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><programlisting><Valve className="org.jboss.web.tomcat.tc5.sso.ClusteredSingleSignOn"
+ cookieDomain="xyz.com"/>
+</programlisting></para>
+ </listitem>
+ </orderedlist>
+ </section>
+ </section>
+
+ <section>
+ <title>Limitations</title>
+
+ <itemizedlist>
+ <listitem>
+ <para>BuddyReplication and ClusteredSSO</para>
+
+ <para>From Jboss 4.0.5 onwards JBoss Cache 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
+ 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
+ out of the SSO on one server, all the cluster members in the cluster
+ 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>
+ </listitem>
+
+ <listitem>
+ <para>Custom Principals and Classloader-issues</para>
+
+ <para>If you use custom principal implementations in your login
+ modules in isolated EAR-files, you need to make sure that their
+ classloaders use exactly the * same * library. You can guarantee this
+ by putting the principal object (and other associated objects) into
+ 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>
+</chapter>
\ No newline at end of file
More information about the jboss-cvs-commits
mailing list