JBOSS 使用集群单点登录SSO

约定不等于承诺〃 2021-11-16 08:34 319阅读 0赞

本文内容来源：JBoss AS 5.1 Clustering Guide  
High Availability  
Enterprise Services  
with JBoss Application

Server Clusters

文中有部分翻译不准，末尾附英文原文

不包含实际应用开发操作，实际应用开发样例及操作后继给出

JBoss 支持集群单点登录，允许一个用户在一个web应用上验证后可以访问集群内同一个虚拟主机上的发布的所有应用程序。验证信息被JBoss Cache复制。集群单点登录支持是由  *org.apache.catalina.authenticator.SingleSignOn *实现的，同时SingleSignOn也是过Tomcat 和JBoss Web 标准中的一部分。无论是否是集群版本都允许用户登录虚拟主机上任意一个web应用，进而获得该用户在虚拟主机上其他应用的访问权限。集群版本的SSO带来的好处就是可以使负载均衡来重定向请求到其他服务器上的webapp。

# 配置 #

要启用集群 single sign-on，你需要在主机配置文件JBOSS\_HOME/server/all/deploy/jbossweb.sar/server.xml中加入ClusteredSingleSignOn 配置。这个配置节点在标准配置文件中已存在，你仅需要取消注释，配置显示如下

节点支持如下属性

*  className 指明应由哪个java类实现此功能。固定设置为：org.jboss.web.tomcat.service.sso.ClusteredSingleSignOn
 *  cacheConfig 集群单点登录使用缓存配置的名称，默认为clustered-sso
 *  treeCacheName 已废弃，使用cacheConfig 。指定Jboss Cache MBean用来做单点登录的 JMX对象名称。如果缓存不能被缓存管理器分配，将使用cacheConfig，尝试将mbean用指定名称注册在JMX中。默认值为jboss.cache:service=TomcatClusteringCache
 *  cookieDomain 指定一组单点登录cookies 使用的主机域名，默认为"/"
 *  maxEmptyLife sessions 的最大空间的时间（秒）。集群SSO组件记录集群节点管理SSO 的session。这个配置非常有用，它使清理节点上SSO登录凭证成为可能。使关闭的本地拷贝失效，从SSO情理所有的session会话。如果maxEmptyLife设置为0，那么SSO将直到本地session拷贝被清理时才会清理，除非集群下其他节点仍旧在使用该session。由于存在session拷贝，且允许SSO存活在用户会话期间内，当有故障发生时，以便可以迅速切换到不同的集群节点。默认值为1800秒（30分钟）
 *  processExpiresInterval 超时处理最小间隔（秒）。指检查maxEmptyLife 超时SSO的间隔时间，该时间不是说明每隔这么长时间就检测，而是说最小检测间隔时间，默认为60秒。
 *  requireReauthentication 指明是否每一次请求均需校验安全凭证。如果设置为true，那么在SSO seesion内，每次请求，组件使用缓存中预留的用户密码重新校验JBoss Web 安全凭证。如果设置为false，组件自己基于SSO cookie进行判断，不再重新认证凭证。如果设置为true可以允许在SOO内 web 应用程序具有不同的安全域（security-domain）配置。默认为false

# SSO行为 #

当用户仅仅访问web应用中未受保护资源时，用户永远不会受到质疑。  
  
  
当用户访问受保护资源时，用户将要被索要认证，使用在web应用中定义的登录方法进行登录。  
  
  
一旦验证，角色被分配后，用户将可以访问受访问控制的所有应用，而不用对各个应用分别进行认证。  
如果web应用的一个session无效（通过调用  *javax.servlet.http.HttpSession.invalidate()*  方法），用户在所有web应用上的会话将会失效。  
  
  
当一个节点会话超时，但另外节点会话仍然有效时，SSO任然有效。

# 限制 #

当使用 Tomcat 组件进行 SSO 实现时，有以下几点需要注意

1.  只能在cluster of JBoss server 中使用，不得用于其他用途。
2.  需要用户容器管理验证（ 通过web.xml 中的 <logic-config>节点 ）
3.  需要cookies支持，SSO通过cookie维护，URL重写技术不支持。
4.  除非requireReauthentication设置为true，所有的web应用配置对同一个SSO组件必须共享同一个JBoss Web 凭证 和 JBoss 安全 Security-domain。这意味

*   *  在server.xml 的Host节点中（或者在Engine节点周围），你能构建 Realm 节点，但是不能再同一个web应用程序的context.xml包中设置。
     *  在jboss-web.xml 或者 jboss-app.xml 中的 security-domain一定要所有的web应用程序设置相同。
     *  即便设置了requireReauthentication 为true ，并且在不同的webapp中使用不同的security-domain（或者相近，不同的认证），不同的认证集成必须接受相同的认证格式（例如，用户名+密码）

# 配置Cookie Domain #

如上所述 SSO插件支持 cookieDomain 配置属性，这个属性允许配置SSO cookie's domain（一组将要持久化存储浏览器cookie的主机）。默认的域名为"/"，意味着浏览器仅持久化cookie到主机并运行它。cookieDomain属性允许cookie 被依附至wider domain

例如，假设我们有个场景，有两个apps，URLs为http://app1.xyz.com 、http://app2.xyz.com ，两个地址希望分享同一个SSO 上下文。这些应用可以运行在一个集群或者虚拟机的不同的服务器上，具有不同的别名。可以支持如下格式配置

8.4. Using Clustered Single Sign On  
JBoss supports clustered single sign-on, allowing a user to authenticate to one web application  
and to be recognized on all web applications that are deployed on the same virtual host, whether  
or not they are deployed on that same machine or on another node in the cluster. Authentication  
replication is handled by JBoss Cache. Clustered single sign-on support is a JBoss-specific  
extension of the non-clustered org.apache.catalina.authenticator.SingleSignOn valve that  
is a standard part of Tomcat and JBoss Web. Both the non-clustered and clustered versions allow  
users to sign on to any one of the web apps associated with a virtual host and have their identity  
recognized by all other web apps on the same virtual host. The clustered version brings the added  
benefits of enabling SSO failover and allowing a load balancer to direct requests for different  
webapps to different servers, while maintaining the SSO.  
8.4.1. Configuration  
To enable clustered single sign-on, you must add the ClusteredSingleSignOn valve to the  
appropriate Host elements of the JBOSS\_HOME/server/all/deploy/jbossweb.sar/server.xml  
file. The valve element is already included in the standard file; you just need to uncomment it. The  
valve configuration is shown here:  
<Valve className="org.jboss.web.tomcat.service.sso.ClusteredSingleSignOn" />  
The element supports the following attributes:  
• className is a required attribute to set the Java class name of the valve implementation to  
use. This must be set to org.jboss.web.tomcat.service.sso.ClusteredSingleSign.  
• cacheConfig is the name of the cache configuration (see Section 3.2.1, “The JBoss AS  
CacheManager Service”) to use for the clustered SSO cache. Default is clustered-sso.  
• treeCacheName is deprecated; use cacheConfig. Specifies a JMX ObjectName of the  
JBoss Cache MBean to use for the clustered SSO cache. If no cache can be located  
from the CacheManager service using the value of cacheConfig, an attempt to locate  
an mbean registered in JMX under this ObjectName will be made. Default value is  
jboss.cache:service=TomcatClusteringCache.  
• cookieDomain is used to set the host domain to be used for sso cookies. See Section 8.4.4,  
“Configuring the Cookie Domain” for more. Default is "/".  
• maxEmptyLife is the maximum number of seconds an SSO with no active sessions will be  
usable by a request. The clustered SSO valve tracks what cluster nodes are managing sessions  
SSO Behavior  
99  
related to an SSO. A positive value for this attribute allows proper handling of shutdown of a  
node that is the only one that had handled any of the sessions associated with an SSO. The  
shutdown invalidates the local copy of the sessions, eliminating all sessions from the SSO. If  
maxEmptyLife were zero, the SSO would terminate along with the local session copies. But,  
backup copies of the sessions (if they are from clustered webapps) are available on other cluster  
nodes. Allowing the SSO to live beyond the life of its managed sessions gives the user time to  
make another request which can fail over to a different cluster node, where it activates the the  
backup copy of the session. Default is 1800, i.e. 30 minutes.  
• processExpiresInterval is the minimum number of seconds between efforts by the valve to  
find and invalidate SSO's that have exceeded their 'maxEmptyLife'. Does not imply effort will be  
spent on such cleanup every 'processExpiresInterval', just that it won't occur more frequently  
than that. Default is 60.  
• requireReauthentication is a flag to determine whether each request needs to be  
reauthenticated to the security Realm. If "true", this Valve uses cached security credentials  
(username and password) to reauthenticate to the JBoss Web security Realm each request  
associated with an SSO session. If false, the valve can itself authenticate requests based on  
the presence of a valid SSO cookie, without rechecking with the Realm. Setting to true can  
allow web applications with different security-domain configurations to share an SSO. Default  
is false.  
8.4.2. SSO Behavior  
The user will not be challenged as long as he accesses only unprotected resources in any of the  
web applications on the virtual host.  
Upon access to a protected resource in any web app, the user will be challenged to authenticate,  
using the login method defined for the web app.  
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  
themselves to each application individually.  
If the web application invalidates a session (by invoking the  
javax.servlet.http.HttpSession.invalidate() method), the user's sessions in all web  
applications will be invalidated.  
A session timeout does not invalidate the SSO if other sessions are still valid.  
8.4.3. Limitations  
There are a number of known limitations to this Tomcat valve-based SSO implementation:  
• Only useful within a cluster of JBoss servers; SSO does not propagate to other resources.  
• Requires use of container managed authentication (via <login-config> element in web.xml)  
Chapter 8. HTTP Services  
100  
• Requires cookies. SSO is maintained via a cookie and URL rewriting is not supported.  
• Unless requireReauthentication is set to true, all web applications configured for the same  
SSO valve must share the same JBoss Web Realm and JBoss Security security-domain. This  
means:  
• In server.xml you can nest the Realm element inside the Host element (or the surrounding  
Engine element), but not inside a context.xml packaged with one of the involved web  
applications.  
• The security-domain configured in jboss-web.xml or jboss-app.xml must be consistent  
for all of the web applications.  
• Even if you set requireReauthentication to true and use a different security-domain  
(or, less likely, a different Realm) for different webapps, the varying security integrations must  
all accept the same credentials (e.g. username and password).  
8.4.4. Configuring the Cookie Domain  
As noted above the SSO valve supports a cookieDomain configuration attribute. This attribute  
allows configuration of the SSO cookie's domain (i.e. the set of hosts to which the browser will  
present the cookie). By default the domain is "/", meaning the browser will only present the cookie  
to the host that issued it. The cookieDomain attribute allows the cookie to be scoped to a wider  
domain.  
For example, suppose we have a case where two apps, with URLs http://app1.xyz.com and  
http://app2.xyz.com, that wish to share an SSO context. These apps could be running on  
different servers in a cluster or the virtual host with which they are associated could have multiple  
aliases. This can be supported with the following configuration:  
<Valve className="org.jboss.web.tomcat.service.sso.ClusteredSingleSignOn"  
cookieDomain="xyz.com" />