确保多个承租者的身份验证和授权的安全在设计软件即服务(Software as a Service，SaaS)应用程序的时候，安全是一项重要的考虑因素，因为数据和过程可能位于组织的管理范围之外。在本文中，您将了解基于 Java™ 2 Platform Enterprise Edition (J2EE) 的、多承租者的、高效的 SaaS 应用程序的各种安全需求，并研究相关的机制，以处理实现用户安全身份验证以及授权的各种需求。

　　引言

　　软件即服务 (SaaS) 业务模型，其目标是减少 IT 成本和所需要的工作，它越来越受到软件行业的关注。在这个模型中，通过 Internet 上的订阅模型来提供应用程序功能。这种业务并不获得软件的所有权，而是订阅远程交付的整体解决方案。使用 SaaS 模型，您可以减少 IT 成本，因为您不再需要支持多个平台和多个版本。然而，因为数据和处理过程由外界提供，所以安全就成了 SaaS 体系结构中最重要的一个问题。

　　因为它将改变软件的构建、使用和交付方式(与传统的软件开发实践相比较)，所以，SaaS 将证明是一种颠覆性的 IT 发展趋势。在开发 SaaS 应用程序和开发企业应用程序之间有一个重要区别，那就是 SaaS 应用程序必须是多承租者的。其他重要的 SaaS 需求，如安全、自定义、面向服务的体系结构 (SOA) 和集成，都会影响 SaaS 应用程序的体系结构。SaaS 是一种颠覆性的发展趋势

　　在本文中，您将了解基于 J2EE 的、多承租者 SaaS 应用程序的应用程序级安全需求，及用来处理这些需求的相关机制。

　　SaaS 应用程序的安全需求

　　多承租者、高效的 SaaS 应用程序具有以下几点安全需求：

　　系统必须提供安全性，并根据相应的权限控制对这些功能的访问。用户数据可能位于一个自行管理的环境中。

　　系统应该提供相应的机制，以便使用自行管理环境中的用户数据对用户进行身份验证，并使用按需环境中的访问控制数据进行授权。由于承租者高度的数据隔离和遵从性需求，用户数据可能位于按需环境中的专用数据库(用于每个承租者)中。

　　系统应该提供一种根据独立的数据库域(对用户所属的承租者进行了配置)进行用户身份验证和授权的机制。用户数据可能位于一个共享的数据库中：

　　在一个按需的环境中，但数据库模式可能有所不同。

　　系统应该提供一种根据共享数据库(为用户所属的承租者配置了不同的数据库模式)进行身份验证和授权的机制。在按需环境的共享模式中。

　　系统应该提供一种根据所有承租者共享的数据库和模式进行用户身份验证和用户授权的机制。用户数据可能位于一个共享数据库中。提供一种机制，以便允许每个承租者的管理员在用户帐号目录中为该承租者创建、管理和删除用户帐号。处理各种需求

　　要处理 SaaS 的应用程序级安全需求，您的体系结构应该处理身份验证和授权需求。在本文中，举例说明了下面两个场景：

　　按需环境中的用户帐号数据库

　　在这个场景中，体系结构应该提供自主构建的安全服务，以便根据集中式的多承租者的用户帐号数据库，以及承租者特定的专用数据库，来进行用户的身份验证和授权。体系结构还应该提供一个接口，以便承租者能够在用户帐号目录中为该承租者创建、管理和删除用户帐号。

　　在单点登录对于客户来说并不是非常重要的情况下，我们推荐使用这种方法。这种方法可以针对使用者用户。自行管理的用户帐号数据库

　　在这个场景中，承租者部署了一种联合服务，它为该承租者自己的用户目录服务提供了接口。当最终用户尝试访问这个应用程序时，承租者的联合服务器将对该用户进行本地身份验证，并与 SaaS 联合服务器进行协商，以便为该用户提供经过签名的安全令牌。SaaS 提供者将使用这个由承租者的联合服务器所颁发的安全令牌进行授权。

　　在单点登录 (SSO) 对于客户来说非常重要的情况下，我们推荐使用这种方法。它还可以针对业务用户。按需环境中的用户帐号数据库

　　为什么您应该自行构建一种安全的解决方案呢?一项重要的技术需求是，SaaS 应用程序可以在一个基础结构中承载多个承租者。为了处理这个需求，SaaS 提供者必须提供一种运行单个 SaaS 应用程序实例的机制，以便容纳来自于该应用程序所支持的所有承租者的用户。

　　图 1 显示了 SaaS 应用程序的一个实例如何为多承租者的用户提供支持。Security Service 为 Tenant 1 和 Tenant 2 的所有用户使用缺省的集中式 Database 1。同时，为了处理 Tenant 3 和 Tenant 4 高度的数据隔离和遵从性需求，Security Service 还必须提供一种机制，以便为 Tenant 3 的所有用户支持专用的 Database 2，并为 Tenant 4 的所有用户支持专用的 Database 3。

　　图 1. 支持多承租者的用户

　　安全框架需要为每个承租者提供独立的域，并提供一种机制以使用该域(以上下文 为基础，对客户所属的承租者进行了配置)对用户进行身份验证。在这个示例中，上下文是决定应用程序的业务操作和使用环境的参数组合(如承租者、业务部门、地理位置，等等)。

　　对于在给定的时间支持多个活动的安全域，基于 J2EE 容器的安全框架存在一定的限制。尽管所有优秀的 J2EE 容器提供了配置多个域的机制，但是一次只能有一个域是活动的。J2EE 安全模型以方法权限为基础，因此对于细粒度的安全访问来说，它既不切实际又很麻烦。

　　所以，为了基于 Java 身份验证和授权服务 (JAAS) 构建自定义的安全服务，您所需要做的就是处理上述的限制。JAAS 是允许服务对用户进行身份验证、并强制实施访问控制的一组 API。通过在应用程序，以及异类的身份验证和授权机制之间放置抽象层，JAAS 可以简化 Java 安全开发。

　　构建基于 JAAS 的自定义安全服务

　　基于 JAAS 的安全服务应该提供完成以下任务的机制：

　　在访问任何业务功能之前建立用户标识。通过维护用户的访问控制列表来提供功能和数据权限。支持用户、组和 ACL 的创建和维护。处理 SaaS 应用程序的多承租需求。允许每个承租者的管理员在用户帐号目录中为该承租者创建、管理和删除用户帐号。与其他的企业应用程序相比，为 SaaS 应用程序构建安全服务的重要区别在于，支持处理多承租的需求。为了处理这个需求，安全服务应该处理下面的事项。

　　捕获用户上下文的方法

　　同样，上下文也是决定 SaaS 应用程序的业务操作和使用环境的参数组合(如承租者、业务部门、地理位置，等等)。4根据大多数承租者的需求，选择缺省的数据体系结构策略。利用一种提供了以下功能的持久性框架：

　　配置驱动机制，该机制允许您使用一个多重数据库策略连接到数据库。使用基于接口的数据访问对象 (DAO) 设计模式来实现持久性逻辑的机制。DAO Config XML 配置驱动机制，以便允许插入到不同的 DAO 实现，并提供了一种映射，以便将 DAO 逻辑名映射为实现细节。对基础 XML 配置的需求，以便与缺省数据体系结构策略的数据库实现交互。提供自定义的 XML 配置，以便与那些需要使用其他数据体系结构策略的承租者的数据库实现交互。提供一种方式，以检索描述每个承租者特定的配置和扩展信息，并根据承租者上下文在运行时插入这些自定义的配置。自行管理的用户帐号数据库

　　SaaS 提供者可以利用商用的、现成的 (COTS) 联合服务器，以便在不同安全域的应用程序中安全地传播联合令牌。SaaS 提供者需要使用联合服务器，这与在按需环境(用于 SSO 解决方案)中的企业客户所使用的其他 SSO 解决方案是可互操作的。位于自行管理环境中的联合服务器必须与 SaaS 提供者的网络中相应的联合服务器具有信任的关系。

　　使用自行管理用户帐号数据库，您还应该：

　　开发一个 Servlet 筛选器，用以从 HTP Header 中检索使用联合服务器进行了身份验证的用户名，并创建一个有效的主体/主题。利用基于 Java 身份验证和授权服务 (JAAS) 的自行构建的安全服务，以便在授权过程中处理 SaaS 的多承租需求。从 Servlet 筛选器调用安全服务应用程序的编程接口 (API)，来对用户进行授权。使用 Controller Servlet of Presentation Framework 配置 Servlet 筛选器，它建立在模型-视图-控制器 (MVC) 设计模式的基础上，用以确保传入的请求满足安全需求。总结

　　在本文中，您了解了处理基于 J2EE 的 SaaS 应用程序的应用程序级安全需求的策略。SaaS 提供者可以使用这些策略，以处理多承租者、高效的 SaaS 应用程序的安全需求。