WebSphere Application Server 常见问题及解答:安全

1. 我希望通过启用 WAS 全局安全性保护系统管理，但是我的应用程序本身并没有应用 J2EE 安全。我能够做些什么呢？

答：
我们强烈建议所有的 WAS 用户使用全局安全。如果没有做这些，就意味着将应用服务器公开给众多种类的攻击。通常情况下，简单启用全局安全对于应用程序并没有任何负面的影响。然而，有一些可测量的性能指标和一些 API，比如 request.getRemoteUser()，在使用安全的情况下会表现出不同的行为。如果应用程序依赖 request.getRemoteUser() 来返回 Web CGI 变量 REMOTE_USER 的值，在应用服务器启用安全的情况下它将崩溃。应用服务器将返回空值，除非用户具备认证属性。我们强烈推荐应用程序利用 J2EE 安全，并且不要禁用服务器级别的安全。

有关 WAS 安全性的更多资源，请参阅 developerWorks 中国站点文章 《专家访谈：KeysBotzum 谈 WebSphere 安全性》。

 

2. 当在 WAS 中实现自定义用户注册表的时候，都需要考虑哪些问题？

答：
自定义用户注册表（UserRegistry 接口的一个实现，简称CUR）使客户使用他们自己的自定义注册表，而不是 WebSphere Application Server 中本来提供的两个：操作系统和 LDAP。首先，我们推荐如果您能避免的话尽量不要使用 CUR，因为这将限制同其他使用 LDAP 的应用程序的互操作性。然而，如果需要的话，您也可以编写一个 CUR。请注意，您自己的自定义注册表实现可能没有依赖任何 WebSphere Application Server J2EE 组件，诸如数据源，企业 Bean 等等。这是因为在启动时，安全是在其他大多数 WebSphere Application Server 组件之前初始化和可用的。如果您以前的实现使用这些组件，则需要做一个更改来消除依赖。比如，如果您的应用以前用数据源来连接一个数据库，那么现在用 Java database connectivity（JDBC）来连接到数据库。注意在小心谨慎的情况下（和对初始化过程的良好理解），在 CUR 中使用 DataSource 也是可能的，但是仅仅在一个应用服务器内部（不是节点代理），并且仅仅在初始化结束以后。

3. 在非 admin 用户（Windows 平台）或非 root 用户（Unix 平台）的环境中，如何为 WAS 设置安全特性？

答：
在非admin用户（Windows平台）/非root用户（Unix平台）环境中运行WAS时，在全局安全（global security）特性被启用的前提下，用户的注册表（registry）必须是LDAP或一个特定的注册表（自定义注册表）。

如果想使用本地操作系统的注册表，运行WAS的用户必须有管理员/root用户的权限来调用本地系统的认证或收集用户/组信息的API。

4. 共享一个 WAS cell 的 J2EE 应用程序需要注意哪些安全方面的问题？

答：

从根本上说，运行在同一个Cell中的应用程序有如下特点：

• 管理操作是共同的，通过管理控制台；
• 资源在JNDI中可见，因此可以被其他应用程序访问到，除非总是使用容器认证和别名；
• 某些WAS子系统，如DynaCache，在内部安全上没有什么规定，因此可被不明应用程序访问；
• 应用程序可访问WAS JMS基础结构，执行任何管理操作，包括改变其他应用程序或cell本身（Java2禁止这种操作）；
• 即使启用了Java 2安全特性，应用程序也可以利用其知名的弱点而绕过Java 2安全检查；

还有很多没列出来的问题。总之，WAS不是被设计成从安全的角度考虑来隔离应用程序的。

5. 在使用基于表单登录的 WAS 应用程序中，为什么必须使用单点登录？

答：
原因是非常简单的。通过使用单点登录（Single sign-on，SSO），WebSphere Application Server 在 Web 请求之间保留用户状态为 LTPA cookie。如果没有使用单点登录，每个单独的请求都需要认证。如果您选择基于表单的登录，一旦表单完成了用户的认证，它将重定向回原始请求的 URL。没有单点登录，用户的认证将丢失并且这些认证将失败。当使用基本的认证时并不会出现这种情况，因为认证信息包含在每个 HTTP 请求中，并且 WebSphere Application Server 在任何需要的时候都可以使用它（这并不影响安全和性能）。

问题：在将本地系统用作 Windows? 上的安全注册表时，WebSphere Application Server 为何需要“Act as part of the operating system”权限？

答：
这个问题的回答实际上是确定的，不过在此我还得使用视情况而定 进行回答。

在任何操作系统上，如果用户注册表保存在本地，WebSphere Application Server 就需要执行本地操作系统调用，用于对底层用户注册表进行认证。对于 Windows，必须有“Act as part of the operating system”权限才能执行特定于 Windows 的本地操作系统调用。（说一点题外话，要在 UNIX? 上使用本地调用，您必须以 root 用户身份运行 WebSphere Application Server，因为 root 是可以查询注册表来获得系统上所有用户 ID 的唯一用户 ID。）我认为，操作系统限制对密码检查 API 进行访问的原因是，如果不加限制，任何用户都可以使用任何用户级程序调用它们，而且有可能使用字典攻击来试图获取用户的密码。强制用户首先获得 root（或作为操作系统的一部分）访问权限来限制此类风险的发生。当然，这种方法不是完美的，但还是有一些帮助。别忘了，这不是“WebSphere 要求”，而只是底层操作系统的要求。

因为操作系统各有特点，所以一般建议将 LDAP 用作安全注册表。这样，在使用不同的操作系统进行部署、测试和生产时，就不必考虑操作系统之间的差异。使用 LDAP 的另一个优点是，在 WebSphere Application Server 使用 LDAP 服务器（通过 LDAP 绑定）进行认证时，您不需要使用 LDAP 管理用户 ID；LDAP 目录中的任何有效的用户 ID 和密码都可以这样使用。另一个方法是使用自定义用户注册表，该注册表在开发环境中使用具有用户 ID 和密码的文件。

因此，除了没有权限的用户外，如果取消授予操作系统权限的要求，则 LDAP 和用户自定义注册表都是不错的选择。

本答案，来自 IBM WebSphere 开发者技术期刊中的 来自 Tom Alcott 的评论:欲言又止的 WebSphere Application Server 的相关问题

问题：WebSphere Applicaitona Server V6.1 在安全方面有哪些增强功能？

答：
A，缺省安全设置

在WAS V6.1 中，很多基本安全配置步骤现在已设置为缺省设置--这样做是为了符合缺省安全 原则。其中的一些例子包括：

• 在安装期间自动启用管理安全性。
• 缺省情况下，会对所有内部传输进行身份验证。
• 缺省情况下，会对大部分内部传输进行加密。缺省情况下，DCS（通常在计算单元内运行）保持未加密状态，但可以为其启用加密。
• 不使用缺省加密密钥，会自动创建计算单元特定的密钥集。
• 缺省情况下，JNDI 对所有人都是只读的（而不是读/写）。

缺省情况下，消息传递将连接仅限制于授予了总线连接角色的经过身份验证的用户。缺省情况下，AllAuthenticated 不再具有此角色。

B，证书、私钥和加密密钥管理

信任存储区和密钥存储区的管理现在作为第一类构造进行处理。这包括管理密钥存储区中的证书和密钥，以及管理整个计算单元内这些密钥的复制。提供了大量小增强功能，这些功能在易用性方面得到了很大的提高。

C，更为复杂的注册中心配置支持

包括支持文件注册中心、可以将多个 LDAP 目录组合为一个逻辑注册中心、直接支持 LDAP 故障转移等。

D，隔离各个管理员

在 V6.1 前，管理授权是在整个计算单元范围内进行的。如果针对个体授予了管理权限，则对计算单元中的每个节点、服务器和应用程序都有管理权限。而通过使用 V6.1，现在可以更精细地对管理权限作用范围进行划分。

E，提供从 Windows 桌面到内部网应用程序的单点登录

WebSphere Application Server V6.1 支持 SPNEGO 信任管理解释器（Trust Association Interceptor，TAI），该解释器允许将 Windows 桌面的 Kerberos 凭据从浏览器发送到 WebSphere Application Server，然后将其作为标识访问 WebSphere 资源。以前发布的 IBM Software Services for WebSphere 提供了一个稍有些不同的 SPNEGO TAI 版本，但现在通过使用 V6.1，我们可获得受到全面支持的产品解决方案。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/14789789/viewspace-375010/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/14789789/viewspace-375010/