JMS基础教程实例(内部).docVIP

JMS基础示例教程 需求分析 在很多实际应用中，不只是简单地要求用户需要注册登录。还要求不同的用户对不同资源拥有不同的权限。某单位的新闻部门的某些人才拥有对外发布新闻的权限；每个部门只有对自己部门内部资源才拥有创建、修改权限，对于其他部门创建的资源如网页等只有浏览的权限。这些复杂的用户权限验证需要可以总结为如下几点： ?????????? 用户资料管理系统：对用户的注册资料进行管理。可进行用户资料的新增修改，能够查询获取丢失的密码。 ?????????? 权限的验证和授权：拦截所有访问受保护资源的请求，检查该用户是否被授权访问该资源。 ?????????? 可控制的资源限制访问：对于系统的资源，无论是数据或行为动作，对确定的一组用户都有限制访问。例如对于有的用户只允许读操作，不能进行写操作；有些资源只有创建者才可以访问和操作等。 这3种需求适合大部分应用系统，通过它们的实现，可以形成一个用户安全管理方面的组件框架，并且能够重复地在不同的应用系统中使用。 ? 2? 架构设计 实现一个完整的用户安全管理框架，可以有两种实现途径。在J2EE出现以前，大部分是由应用系统本身实现。因此，很多有经验的软件商都拥有自己成熟的用户安全管理系统，但是缺点也是比较明显，自己设计的用户安全管理系统可重用性低，有的和具体应用程序过分紧密地绑定在一起，无法移植到其他系统上。 但是，随着业务量上升，应用系统的不断增加，会出现不同应用系统拥有不同的用户登录验证体系，很显然，这给用户访问带来了不方便，用户不可能为每个系统注册一套用户和密码，定制一套用户角色。因此，整个服务器群中需要统一的用户权限验证体系。而J2EE容器的用户安全管理框架再辅助以LDAP或数据库系统，可以很方便地达到这个目标。 2.1? 角色 J2EE容器的用户安全框架是基于RBAC（Roled-Based Access Control，相关网址：/rbac/）设计模型建立的，这是一个基于角色的访问权限控制模型。 首先必须了解角色的含义，在RBAC中角色Role的定义是：Role是明确表达访问控制（Aceess Control）策略的一种语义构建词。 角色可以是指做某些事情的资格，比如医生或物理学家；也可以包含权力和责任的意思，如部门经理或局长等。角色和组（groups）是有区别的。组就是纯粹代表一群用户；角色一方面代表一系列用户，另外一方面可以代表一系列权限，因此可以说是用户和权限的结合体。 引入角色的概念主要是为了分离用户和访问权限的直接联系。用户与访问权限的直接组合可能是短暂的，而角色则可以相对稳定，因为一个系统中和角色相关的权限变化是有限的。 在RBAC理论出现之前，很多人都是把用户和权限混淆在一起，这样当用户或权限发生变化时，都会涉及到对方，很显然这在实际实现中将是非常复杂的。所以诞生RBAC，创造了一个“角色”的名词，注意这是人为创造的语义词。角色就是用户和权限之间的第3者，通过引入角色概念，将用户和权限的关系解耦。这样用户的变化只要涉及到角色就可以，无需考虑权限。而权限的变化只涉及到角色，无需考虑用户或用户组。 因此，基于角色的访问控制系统可以分为两个部分：与角色相关的访问权限系统以及与角色相关的用户管理系统。这样，通过角色这个中间者，将用户和权限联系在一起。其实这也非常符合日常生活的逻辑，例如王三来到某公司做业务员，公司章程规定了业务员一定的权限和职责，王三进入了业务员的角色，王三也就有了这些权限和职责，但这些权限职责不是和王三本人有直接联系的，而是通过王三的角色才会发生在王三身上；如果王三升迁做经理，表示其进入经理这样的角色，由此经理角色拥有的权限和职责王三又会拥有。 由于有了这样两个分离的系统，因此在具体应用上可以分别实现，在J2EE中，与角色相关的访问权限是通过配置文件（Web.xml和ejb-jar.xml）由容器自动实现的，而且这种访问权限的配置也是非常方便灵活的。 而与角色相关的用户系统则由具体应用系统的开发者来实现，可以采取基于数据库或LDAP等技术的数据系统来实现，例如用户注册资料的新增和修改等。 本项目的设计思路就是完全按照这两种分离的思路实现的，将与角色相关的访问权限系统交由J2EE容器实现。因此，如何配置J2EE将是本项目实现中的一个主要部分；代码设计编程则主要集中在基于数据库的用户管理系统上。 2.2? J2EE的JAAS J2EE容器实现了与角色相关的访问权限功能，如何在自己的具体应用系统开发中使用J2EE的安全系统？ 通过使用J2EE容器提供的JAAS （Java Authentication Authorization Service，Java验证和授权API），JAAS是J2EE服务器用来帮助应用系统实现安全功能的。当应用系统的开发者具体实现