在WebSphere Studio V5中使用定制注册中心测试J2EE安全性应用程序的方法
在WebSphere Studio V5中使用定制注册中心测试J2EE安全性应用程序的方法
http://www-900.ibm.com/developerWorks/cn/wsdd/techjournal/0303_barcia/barcia.shtml© Copyright International Business Machines Corporation 2003. All rights reserved.
引言
随着应用程序越来越多地利用 J2EE 安全性以实现某些功能（例如定制菜单或个性化），拥有支持 J2EE 安全性的开发环境也变得愈发重要。由于 J2EE 安全性概括了基本的安全性实现，开发人员可以利用平面文件、本地操作系统或测试 LDAP 服务器来测试自己的 J2EE 应用程序，同时生产系统可以在使用高级 LDAP 注册中心的情况下运行。
WebSphere 应用程序开发人员通常将本地操作系统用于开发安全性实现，通过 Start => Settings 菜单选项增加用户和组以及改变安全策略。但如果使用 Windows 的开发机器属于某个 Windows 域 － 这种情况的可能性很大，那么设置安全性将变得非常复杂。由于安装在测试环境的 WebSphere Application Server 版本是与生产环境相同的完整版，测试和生产中的安全性以相同的方式运作，包括在搜索本地注册中心之前先在整个域中搜索用户。在开发环境中，开发者经常启动和停用服务器，在等待服务器启动以验证用户时发生延误是经常的事，这潜在地妨碍了生产效率。同样的，在其它操作系统上，局域网管理员通常喜欢维持对安全性设置的控制，只为开发者保留很小的灵活性。
幸运的是，本地操作系统并不是唯一的安全性选项。另一种用于测试目的的安全性实现方法是使用基于文件的定制注册中心。
WebSphere Application Server V5 带有一个 FileRegistrySample，不需额外编写代码即可安装，遵循一个简单的文件格式，可用于大多数 J2EE 安全性开发工作。FileRegistrySample 使用两个文件：一个用于用户，一个用于组。由于开发者出于测试目的通常只需要少数几个示例用户，这些文件很容易维护。开发者不仅可以在 WebSphere Studio 工作空间维护这些文件，还可以在团队环境下将其共享。
使用 FileRegistrySample 是一种简单的方法，可以为 J2EE 开发者提供在测试环境下实现复杂安全性的一种替代方案。当测试的应用程序使用简单 J2EE 安全性，即使用说明角色模型或 isUserInRole() 之类的方法调用时，FileRegistrySample 是最佳选择。如果需要，开发者可以将 FileRegistrySample 作为示例，用 XML 格式实现更为健壮的注册中心。如果应用程序使用更为复杂的安全性选项，例如利用 LDAP 属性，那么在开发中拥有一台可用的 LDAP 服务器将是值得考虑的。
本文将引导您完成在 WebSphere Studio Application Developer 中设置 FileRegistrySample。我们将导入带有 2 个 JSP 页的 EAR 文件，每页映射到不同角色。之后安装应用程序服务器以使用 FileRegistrySample，再使用应用程序对其进行测试。我们还将回顾一些基本的 J2EE 安全性。
本文假定读者具有对 J2EE 安全性、WebSphere Application Server 和 WebSphere Studio Application Developer 的基本理解。需要 WebSphere Studio Application Developer，版本 5 的一个副本，以便自始至终明确遵循分级步骤。
要了解关于写定制注册中心的信息，请参阅参考资料。
导入示例 EAR
首先，从下载部分导入测试应用程序：
-
将压缩文件解压到
C:/目录。这将在您的机器上创建名为security的子目录。 -
打开 WebSphere Studio Application Developer 并在图 1 所示的对话框中输入
C:/Security/workspace。（如果您使用另一个工作空间目录，请记下该目录以便以后配置 FileRegistrySample。）
图 1. 打开工作空间
- 当工作空间已打开，转至 J2EE 透视图。从主工具栏选择 File => Import。
- 选择 EAR File 之后单击 Next（参见图 2）。
图 2：导入 EAR 文件
-
在下一屏（图 3），指定 EAR File，通过浏览或输入
C:/Security/SecurityApp.ear。 -
针对 Project name 输入
SecurityApp。 - 选择 Finish。
图 3. 安全性应用程序
浏览应用程序
SecurityApp 是很简单的应用程序。它带有 2 个 JSP 页，每页映射到相应的角色：
JSP 角色 resource1.jsp角色 1 resource2.jsp角色 2
打开 Web Deployment Descriptor 查看角色：
- 转至 J2EE Navigator 视图。
- 扩展 SecurityWebApp 并双击 Web Deployment Descriptor（图 4）。
图 4. 打开 Web Deployment Descriptor
- Web Deployment Descriptor 编辑器在一个选项卡窗口中打开（图 5）。选择 Security 选项卡。
图 5. 用于 Web Deployment Descriptor 的安全性选项卡
- 在所显示的安全性对话框，Security Roles 子选项卡是用于定义我们的 J2EE 角色（图 6）。针对我们的例子，角色已经创建。记住下面这一点是很重要的，“角色”是一个抽象概念；它将映射到相应的概要文件，例如某个基础安全性实现的一个组的概要文件。针对 JSP 页，角色代表某个组，允许其中成员查看该 JSP 页，通过一个安全性约束一同映射。针对基本的安全性，角色可以直接映射到一个组，或者组可以映射到多个角色。安全性实现（例如 Tivoli_Access Manager）也可以决定将角色作为应用程序对象来处理。决定如何将角色映射到组以及如何将角色指派到资源需要仔细计划，并应该在应用程序设计阶段的早期完成。基于使用场合和界面设计确定角色将有助于 J2EE 安全性实现的成功和有效性。
图 6. 角色
- 迄今为止，我们一直在 J2EE 规范下工作。如果您查看用于我们的部署描述符的 XML 源代码，就会发现创建角色将更新我们的部署描述符，就像 J2EE 规范所要求的那样。在图 7 中选择 Source 选项卡，并在清单 1 的源代码中查找 XML 标记。
图 7.Web XML 源代码
清单 1.
<security-role>
<description></description>
<role-name>Role1</role-name>
</security-role>
<security-role>
<description></description>
<role-name>Role2</role-name>
</security-role
- 切换回 Security 选项卡（图 5）。
- 在所显示的安全性对话框中，选择 Security Constraints 子选项卡（图 8）。安全性约束非常类似于访问控制列表（Access Control List，ACL）。它将用户或组匹配到特定资源以及用户或组对资源进行操作的权限。例如，Tivoli Access Manager 使用 ACL 允许组 A 对文件 1 拥有写权限。安全性约束在您的 J2EE 应用程序中实现相同功能，但使用角色：可以说角色 1 对 JSP 页 1 拥有 HTTP GET 和 POST 权限。使用角色使得我们的 J2EE 安全层同实际实现相分离。
- 选择第一个 SecurityConstraint，如图 8 所示。
图 8. 安全性约束
- 在 Web 资源集合部分，在编辑器的右侧（图 9），我们可以定义一个安全性约束以映射到针对多项资源的多重权限。选择 resource1 并单击 Edit。
图 9. 编辑资源集合
-
在 Web 资源集合对话框，您可以选择允许的 HTTP 方法，为资源添加 URL 模式。在图 10 中，Role1 允许对映射到 URL 模式
/resource1.jsp的资源拥有 GET 和 POST 权限。
图 10. Web 资源集合
- 单击 Cancel。
- 在 Authorized Roles 部分，在编辑器的右侧（图 9），我们可以定义与安全性约束相连的角色。这仍处于 J2EE 规范内。
-
如果您回顾我们的 Web Deployment Descriptor 源代码，就应该发现清单 1 中所示的标记，该清单说明安全性约束如何象逻辑 ACL 一样工作，使用逻辑角色保护物理资源。安全性约束 2 非常类似，以同样的方式将
/resource2.jsp匹配到 Role2。
清单 2.
<security-constraint>
<web-resource-collection>
<web-resource-name>resource1</web-resource-name>
<description></description>
<url-pattern>
/resource1.jsp</url-pattern>
<http-method>
GET</http-method>
<http-method>
POST</http-method>
</web-resource-collection>
<auth-constraint>
<description></description>
<role-name>Role1</role-name>
</auth-constraint>
</security-constraint>
- 最后，转至 Web Deployment Descriptor 的 Pages 选项卡，如图 11 所示。
图 11. Pages 选项卡
- 在登录段中指定认证方法（图 12）。我们将使用“Basic”，它提示您使用标准浏览器。 清单 3 说明定义认证机制的源标记。 要了解其它认证机制的信息，请参阅参考资料中的 WebSphere V5.0 Security Handbook。
图 12. 基本认证
清单 3.
<login-config>
<auth-method>BASIC</auth-method>
</login-config>
- 关闭 Web Deployment Descriptor 编辑器。
我们目前所作的全部工作都遵循 J2EE 规范。但 J2EE 规范并未指明角色如何映射到基础安全实现，这无关紧要，因为我们希望它是灵活的。为做到这一点，WebSphere 使用称为绑定文件的分离 XMI 文件，利用 Enterprise Application Deployment Descriptor 编辑器。这一编辑器维护遵循规范的 application.xml 和 WebSphere 绑定文件，利用清晰标注的段使您了解它属于哪一基础文件。
- 通过展开 SecurityApp => EAR Deployment Descriptor，从 J2EE Navigator View 中打开 EAR Deployment Descriptor（图 13）。
图 13. EAR Deployment Descriptor
- 在 EAR Deployment Descriptor 中，选择 Security 选项卡，如图 14 所示。
图 14. Security 选项卡
-
在左侧，您将看到我们的角色如同
web.xml中一样进行定义。当您选择 Gather 按钮时，如图 15 所示，WebSphere Studio Application Developer 轻松的从子模块中收集角色，将它们添加到application.xml中。 - 您还可以选择 Source 选项卡（图 14）来检查代表收集的角色的源代码（清单 4）。
图 15. 收集安全性角色
清单 4.
<security-role>
<description></description>
<role-name>Role1</role-name>
</security-role>
<security-role>
<description></description>
<role-name>Role2</role-name>
</security-role>
- 为将角色绑定到物理用户和／或组，请选择角色，如图 16 所示。
图 16. 选择角色 1
- 如图 17 所示，角色可以映射到特定的用户和／或组，同样可以映射到全体用户或仅映射到认证用户。对于本测试，我们将 Role1 映射到 Group1。该映射在名为 WebSphere Bindings 的段之下指定，这意味着关于 J2EE Deployment Descriptor 的抽象内容必须与相应的实物相联系。这是贯穿于 EAR、WEB 和 EJB Deployment Descriptor 编辑器的一致性概念。在此例中，我们将抽象角色绑定到实际的组。（WebSphere Bindings 也称为 WebSphere Extensions，表示其功能超出 J2EE 规范。）
图 17. 将角色绑定到组
-
因为我们已经更新过一个绑定，我们需要查看绑定源代码，而不是
application.xml源代码。我们可以通过扩展 SecurityApp => META-INF 来打开用于 EAR 的绑定文件，如图 18 所示，并检查清单 5 中显示的源代码的标记。
图 18. 绑定文件
清单 5.
<?xml version="1.0" encoding="UTF-8"?>>
<applicationbnd:ApplicationBindingxmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI"xmlns:applicationbnd="applicationbnd.xmi"xmlns:common="common.xmi" xmlns:application="application.xmi"xmi:id="ApplicationBinding_1042838113181">
<authorizationTable xmi:id="AuthorizationTable_1042838113191">
<authorizations xmi:id="RoleAssignment_1042838113191">
<role href="META-INF/application.xml#SecurityRole_1042838113191"/>
<groups xmi:id="Group_1042838113952"name="Group1"/>
</authorizations>
<authorizations xmi:id="RoleAssignment_1042838113952">
<role href="META-INF/application.xml#SecurityRole_1042838113952"/>
<groups xmi:id="Group_1042838113962"name="Group2"/>
</authorizations>
</authorizationTable>
<application href="META-INF/application.xml#Application_ID"/>
</applicationbnd:ApplicationBinding>
-
此处关键一点是，认证段将
application.xml中定义的角色映射到组名。角色标记中的xmi:id（角色的散列表示）作为角色反向联入application.xml的链接，并为之分配一个组。在此例中，Role1 映射到 Group1，而 Role2 映射到 Group2。 - 关闭文件。
导入用户和组文件
既然我们已浏览了这个简单示例并了解了一些 J2EE 安全性基础，现在我们就可以安装文件注册中心。
- WebSphere FileRegistrySample 需要两个文件（都包含在下载部分的压缩文件中）：一个维护用户，另一个维护组。使用 File => Import 命令将这些文件导入到您的工作空间。当导入向导显示时，选择 File system => Next，如图 19 所示。
图 19. 导入向导 — 文件系统
-
在下一屏，图 20 中，浏览到或指定包含此处可下载的压缩文件的目录，例如
C:/Security。 -
在右侧，选中
users.prop和groups.prop。 -
针对 Folder，指定
SecurityAppWeb，并选择 create selected folders only。
图 20. 导入安全性文件
-
在安装文件注册中心之前先检查这两个文件。首先打开
users.prop文件。从 J2EE Navigator 视图，展开 SecurityAppWeb 并打开users.prop（图 21）。
图 21. users.prop
-
users.prop文件中配置了两个用户：User1 和 User2。（清单 5）文件遵循一个非常简单的格式，如清单 6 所示。
清单 5.
user1:password:123:567,987:User1
user2:password:345:789:User2
清单 6.
<user name>:<password>:<unique user identifier>:<identifiers of groups user belongs to commas separated>:<Display Name>
-
现在以同样的方式打开
groups.prop文件（图 22）。清单 7 显示配置的三个组，清单 8 说明简单文件格式。注意groups.prop中定义的组标识用于文件users.prop。
图 22. 打开 groups.prop
清单 7.
group1:567:user1:Group1
group2:789:user2:Group2
admin:987:user1:Admin
清单 8.
<group-name>:<group identifier>:<users that belong to the group comma separated>:<display name>
记住这一文件格式是作为构建定制注册中心的示例而提供的，但并不是说我们不可以为安全性而将其用做本地操作系统的开发替代。如果您想这么做，可以创建自己的文件注册中心。
同时注意这些文件必须驻留在 sync 中；如果您向组中添加用户，两个文件都需要更新。
不推荐把平面文件用于安全性，指出这一点是很重要的。我们在这里使用它是因为我们专门处理开发方案。相反的，生产环境应该使用明显更为健壮的安全性解决方案，例如 LDAP 注册中心或 Tivoli Access Manager。想了解更多关于安全性生产建议或创建自己的开发文件注册中心的信息，请参阅参考资料部分中的 WebSphere V5.0 Security WebSphere Handbook。
创建并配置服务器
现在我们创建服务器并启用管理客户机。在此之后，我们可以通过 WebSphere ApplicationServer V5 管理控制台来完成配置工作。
我们可以通过使用管理控制台或 WebSphere Studio 编辑器来配置测试应用服务器，WebSphere Studio 编辑器实际包含了管理控制台的一个子集合。WebSphere Studio 编辑器包含开发者所需的大多数配置选项，而管理控制台包含额外的设置，对于开发者而言并非必要，例如群集服务器。不能通过 WebSphere Studio 配置的一个或两个功能是典型的由操作系统进行处理的功能。安全性是其中之一，这也是我们需要转向管理控制台来设置定制文件注册中心作为安全性实现的原因。
要创建服务器并查看安全性信息：
- 通过单击窗口左上角的 Perspective 按钮，切换到 Server 透视图（图 23）。
图 23. 打开 Server 透视图
- 将显示一个带有若干透视图选择的下拉式菜单。选择 Server（或选择 Other => Server，如果 Server 未显示的话）。
- 在 Server Configuration 视图中，用鼠标右键单击 Servers 文件夹（图 24）。
图 24. 服务器配置
- 选择 New => Server => Server Configuration。这将打开新建服务器向导（图 25）。
-
输入下列数据：
-
服务器名称：
WAS5 -
文件夹：
Servers - 服务器类型：展开 WebSphere version 5 并选择 Test Environment
- 保留所有其它值为默认值。
-
服务器名称：
图 25. 新建服务器
- 返回 Server Configuration 视图打开 Server Configuration 编辑器（图26），展开 Servers 并双击 WAS5。
图 26. 打开服务器配置
- 在 Server Configuration 编辑器上选择 Security 选项卡（图 27），检查不同的安全性选项（图 28）。
图 27. Security 选项卡
- Enable security 复选框将自动配置您的测试服务器以便为了安全目的使用本地操作系统（图 28）。这也可以通过使用管理控制台来实现。
图 28. Security 段
- 如前所述，我们不能从任何 WebSphere Studio Application Developer 编辑器安装定制注册中心，但可以使用管理控制台来做到这一点。默认情况下，在 WebSphere Studio 中创建的测试服务器上是禁用管理控制台的。但是，管理控制台可以通过 Server Configuration 编辑器内的 Configuration 选项卡简单地加以激活。
图 29. Configuration 选项卡
- 选中 Enable administrative console（图 30）。
- 保存并关闭配置文件。
图 30. 启用管理控制台
安装定制注册中心
现在我们已经准备好配置我们的定制注册中心，使其使用 FileRegistrySample，并启用全局安全性使之使用定制注册中心。
- 我们需要启动服务器并打开管理控制台，它是在 WebSphere Application Server 内部运行的 Web 应用程序。为实现这一点，转向 Servers 视图。
- 用鼠标右键单击 WAS5 服务器并选择 Start（图 31）。现在控制权应该切换到控制台。
图 31. 启动服务器
- 等待“Open for e-business message”，之后返回 Servers 视图。
- 再次用鼠标右键单击 WAS5 服务器，之后选择 Run Administrative Client。这将调出浏览器并显示管理控制台的登录屏幕。（如果没有，打开浏览器并转向 http://localhost:9090/admin。）
- 由于未启用安全性，您将得到仅关于一个用户 ID 的提示，但该用户 ID 必须是您当前使用来登录操作系统的 ID。一旦我们启用安全性以使用定制注册中心，您将需要使用在用户文件中定义的用户 ID 之一。同时，输入您当前的用户 ID，并选择 OK（图 32）。
图 32.
- 下一步，从管理控制台的 Navigation 菜单，展开 Security => User Registries =>Custom（图 33）。这将带您来到 User Registry 屏幕（图 34）。
图 33. 定制用户注册中心
-
在 User Registry 窗口（图 34），我们需要输入数据来实现 FileRegistrySample 例子中我们所使用的用户注册界面。由于我们使用 FileRegistrySample，我们需要确保输入来自
users.prop文件的有效用户 ID；我们将使用 User1。服务器同样需要这个 ID。因为这用于开发辅助工具，我们不必担心对管理控制台的保护，但如果您希望的话，您可以指派管理角色之一。输入下列信息：-
Server User ID:
user1 - Server User Password: password
-
Custom Registry Classname:
com.ibm.websphere.security.FileRegistrySample
-
Server User ID:
- 选择 Apply。
- 单击 Custom Properties。
图 34. 配置定制用户注册中心
-
由于 FileRegistrySample 使用两个属性文件，
users.prop和groups.prop，我们需要告知它这些文件所在的位置。在 Custom Properties 窗口，按 New，之后按 Enter，再输入下列数据（图 35）：-
Name:
usersFile -
Value:
c:/Security/workspace/SecurityAppWeb/users.prop
c:/security/workspace。（在团队环境下，您可以配置名为workspace的环境变量。） -
Name:
图 35. 设置 usersFile 属性
- 单击 OK。
-
再次单击 New，之后输入下列数据（图 36）：
-
Name:
groupsFile -
Value:
c:/Security/workspace/SecurityAppWeb/groups.prop
-
Name:
图 36. 设置 groupsFile
- 单击 OK。现在，用户和组属性应该已正确配置，如图 37 所示。
图 37. 定制属性
- 在成功配置定制注册中心之后，现在我们需要启用全局安全性。从导航菜单栏选择 Security => Global Security（图 38）。
图 38. 全局安全性链接
- 在 Global Security 窗口（图 39），选中 Enabled 框来启用 Global Security。取消选择 Enforce Java 2 Security；Java 2 Security 使用策略文件来保护不同的资源，但此类严格的限制对于我们的开发实现而言并非必需。
- 针对 Active User Registry，从列表中选择 Custom。
- 为剩余的字段保留默认值。
- 按下 OK。
图 39. 全局安全性
- 既然所有必需的更改已完成，我们需要通过保存配置来持续所作的更改。单击上方菜单的 Save，或者如果显示消息对话框（图 40），单击其中的 Save 链接。
- 在保存窗口（图 41）单击 Save来作出最终配置更改。
图 40. 保存链接
图 41. 按下 save 键。
- 最后，在上方菜单栏中选择 Logout（图 42）。
- 关闭浏览器。
图 42. 注销
- 停用服务器。在 Server 视图，用鼠标右键单击 WAS5 并选择 Stop（图 43）。
图 43. 停用服务器
部署并测试应用程序
我们现在已准备好部署并测试应用程序。我们将把应用程序添加到服务器配置当中，启动服务器并使用 User1 和 User2 访问每一资源。我们还将查看管理控制台登录屏幕，并确保其已改为使用安全性登录表单。我们将使用一个浏览器，但由于使用基础认证，我们需要通过先关闭再打开浏览器的方式来分离浏览器和用户。（WebSphere Studio 浏览器存储用户以用于基础认证，即使它已经关闭，因此推荐您使用 Miscrosoft_Internet Explorer 或 Netscape_Navigator 以便成功运行此测试。）
- 为向服务器添加我们的应用程序，通过展开 Servers => WAS5 => Add =>SecurityApp 转向 Server Configuration 视图。您的视图应该类似图 44 所示。
图 44. 部署应用程序
- 返回 Server 视图，用鼠标右键单击 Server，如图 45 中 WAS5，并选择 Start。
图 45. 启动服务器
- 一旦服务器已启动，打开一个 Web 浏览器（例如 Internet Explorer 或 Netscape）并输入下列 URL：http://localhost:9080/SecurityAppWeb/resource1.jsp。
-
浏览器应该呈现基本认证提示，如图 46 所示。输入：
-
User Name:
user1 -
Password:
password
-
User Name:
图 46. User1 登录
- 如果您还记得的话，User1 允许查看 resource1，但不允许查看 resource2。 针对第一个 URL，您应该获取如图 47 所示的消息。
图 47. resource 1 上的 User 1
- 现在，在同一个浏览器中输入下列 URL：http://localhost:9080/SecurityAppWeb/resource2.jsp。您应该获取“403: AuthorizationFailed”错误信息，如图 48 所示。
图 48. Resource 2 上的 User 1
- 关闭浏览器。
- 打开一个新的浏览器并输入下列 URL：http://localhost:9080/SecurityAppWeb/resource2.jsp（图 49）。
-
这一次使用下列信息登录：
-
User Name:
user2 -
Password:
password
-
User Name:
图 49. User 2 登录
- 由于 User 2 在试图访问 resource2，成功信息将同图 50 中的消息一起显示。
图 50. resource 2 上的 User 2
- 在同一个浏览器中，输入下列 URL：http://localhost:9080/SecurityAppWeb/resource1.jsp。
- 由于 User 2 不允许查看 resource1，我们应该获得如图 51 所示的错误消息。
图 51. Resource 1 上的 User 2
现在我们用简单的基于文件的注册中心使 J2EE 安全性开始工作了。
使用基于文件的注册中心的一个副作用是，管理控制台用户也从属于文件注册中心。针对一个最终测试，返回 Servers 视图，用鼠标右键单击 WAS5 并再次运行管理客户机。这一次，用于管理控制台的登录表单将要求用户 ID 和密码（图 52）。为进入，输入：
-
User Name:
user1 -
Password:
password
图 52. 安全管理登录
结束语
在本文中我们了解到，本地操作系统并不是开发者在 WebSphere Studio 之内测试 J2EE 应用程序的唯一选择，因为开发者可以改为使用类似基于文件的注册中心或 LDAP 服务器等资源（甚至在开发过程中）。我们回顾了一些基础的 J2EE 安全性，检查了用于安全性的 Web 和应用程序部署描述符编辑器选项，并描述了如何将它们映射到基础安全性实现。最后，我们配置并测试了 FileRegistrySample，部署了应用程序，并测试了安全性。
如同许多 J2EE 功能一样，用于实现的基础机制是抽象出来的；这是 J2EE 的诸多好处之一。开发者应该能够测试某个功能，而不需要基础生产系统的全部内容。安全性并无不同。开发者拥有不同的选择来配置他们的测试安全性以满足开发需求，不必为安全环境而降低要求。
参考资料
- IBM WebSphere V5.0 Security WebSphere Handbook Series
- 与 WebSphere Portal 一同使用定制注册中心
- IBM Tivoli Access Manager 3.9 与 WebSphere Application Server 的集成：完整的安全性解决方案