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

1. 我想通过启用WAS全局安全性来保护系统管理，但是我的应用程序本身并不适用J2EE安全性. 我该怎么办？

答案:

我们强烈建议所有WAS用户使用全局安全性. 否则，将使应用程序服务器遭受多种攻击. 通常，仅启用全局安全性不会对应用程序产生负面影响. 但是，有一些可衡量的性能指标和一些API，例如request.getRemoteUser（），它们在使用安全性时的行为会有所不同. 如果应用程序依赖request.getRemoteUser（）返回Web CGI变量REMOTE_USER的值，则如果在应用程序服务器上启用了安全性，它将崩溃. 除非用户具有身份验证属性，否则应用程序服务器将返回空值. 我们强烈建议应用程序利用J2EE安全性，并且不要禁用服务器级安全性.

有关WAS安全性的更多资源，请参阅developerWorks中国网站上的文章“专家访谈: WebSphere Security上的KeysBotzum”.

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

答案:

自定义用户注册表（UserRegistry接口的实现，简称CUR）使客户可以使用自己的自定义注册表，而不是WebSphere Application Server中最初提供的两个: 操作系统和LDAP. 首先，如果可以避免，我们建议不要使用CUR，因为这将限制与使用LDAP的其他应用程序的互操作性. 但是，如果需要，您可以编写CUR. 请注意，您自己的自定义注册表实现可能不依赖于任何WebSphere Application Server J2EE组件，例如数据源，企业Bean等. 这是因为在启动时，安全性已初始化并且在大多数其他WebSphere Application Server组件之前可用. 如果您以前的实现使用了这些组件，则需要进行更改以消除依赖关系. 例如ibm websphere 单点登录原理，如果您的应用程序曾经使用数据源连接到，那么现在使用Java连接（JDBC）连接到. 请注意，请谨慎（并充分了解初始化过程），也可以在CUR中使用DataSource，但只能在应用程序服务器（而非节点代理）中使用，并且只能在初始化完成之后使用.

3. 在非管理员用户（Windows平台）或非root用户（Unix平台）的环境中，如何设置WAS的安全性功能？

答案:

在非管理员用户（Windows平台）/非root用户（Unix平台）环境中运行WAS时，用户的注册表（注册表）必须是LDAP或特定注册表（自定义注册表）.

如果要使用本地操作系统的注册表，则运行WAS的用户必须具有管理员/ root用户权限才能调用API进行本地系统身份验证或收集用户/组信息.

4. 共享WAS单元J2EE应用程序时应注意哪些安全问题？

答案:

从根本上说，在同一单元中运行的应用程序具有以下特征:

仍有许多未列出的问题. 简而言之ibm websphere 单点登录原理，WAS并非旨在从安全角度隔离应用程序.

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

答案:

原因很简单. 通过使用单点登录（SSO），WebSphere Application Server在Web请求之间将用户状态保持为LTPA cookie. 如果不使用单点登录，则每个单独的请求都需要认证. 如果选择基于表单的登录，则表单完成用户身份验证后，它将重定向回到原始请求的URL. 没有单点登录，用户身份验证将丢失并且这些身份验证将失败. 使用基本认证时不会发生这种情况，因为认证信息包含在每个HTTP请求中，并且WebSphere Application Server可以在需要时使用它（这不会影响安全性和性能）.

问题: 为什么在Windows上将本地系统用作安全注册表时，WebSphere Application Server为什么需要“充当操作系统的一部分”权限？

答案:

这个问题的答案实际上是可以的，但是在这里我必须根据情况使用答案.

在任何操作系统上，如果用户注册表存储在本地，则WebSphere Application Server需要执行本地操作系统调用以对基础用户注册表进行身份验证. 对于Windows，必须具有“充当操作系统的一部分”权限才能执行特定于Windows的本地操作系统调用. （作为题外话，要在UNIX？上使用本地调用，您必须以root用户身份运行WebSphere Application Server，因为root是可以查询注册表以获取系统上所有用户ID的唯一用户ID. ）系统限制访问密码检查API的原因是，没有限制，任何用户都可以使用任何用户级程序来调用它们，并且有可能使用字典攻击来尝试获取用户密码. 强制用户首先获得root用户（或作为操作系统的一部分）的访问权限，以限制此类风险的发生. 当然，这种方法并不完美，但是仍然有一些帮助. 不要忘记，这不是“ WebSphere要求”，而仅仅是底层操作系统的要求.

由于操作系统具有各自的特征，因此通常建议使用LDAP作为安全性注册表. 这样，当使用不同的操作系统进行部署，测试和生产时，无需考虑操作系统之间的差异. 使用LDAP的另一个优点是，当WebSphere Application Server使用LDAP服务器（通过LDAP绑定）进行身份验证时，您不需要使用LDAP来管理用户标识；而是使用LDAP来管理用户标识. 可以使用LDAP目录中的任何有效用户ID和密码. 另一种方法是使用自定义用户注册表，该注册表在开发环境中使用带有用户ID和密码的文件.

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

此答案来自IBM WebSphere开发者技术期刊上Tom Alcott的评论: 与WebSphere Application Server问题有关的评论

问题: WebSphere Applicaitona Server V6.1的安全性增强是什么？

答案:

A，默认安全设置

在WAS V6.1中，许多基本安全性配置步骤现已设置为默认设置-这样做是为了遵守默认安全性原则. 一些示例包括:

默认情况下，消息传递将连接限制为已被授予总线连接角色的经过身份验证的用户. 默认情况下，AllAuthenticated不再具有此角色.

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

现在将信任存储区和密钥存储区的管理作为第一类结构. 这包括管理密钥存储区域中的证书和密钥，以及管理整个计算单元中这些密钥的复制. 提供了许多小的增强功能，这些功能在易用性方面得到了很大的改进.

C，更复杂的注册表配置支持

包括对文件注册中心的支持，将多个LDAP目录合并为一个逻辑注册中心的能力以及对LDAP故障转移的直接支持.

D，隔离每个管理员

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

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

WebSphere Application Server V6.1支持SPNEGO信任关联（TAI），它允许将Windows桌面的Kerberos凭据从浏览器发送到WebSphere Application Server，然后用作访问WebSphere资源的标识. 先前发布的IBM WebSphere软件服务提供的SPNEGO TAI版本略有不同，但是现在通过使用V6.1，我们可以获得完全受支持的产品解决方案.

本文来自电脑杂谈，转载请注明本文网址：
https://www.pc-fly.com/a/jisuanjixue/article-225960-1.html