J2EE安全体系（二）

日期	2005年8月1日
作者	gauss
类型	安全认证
内容	电子平台的安全模式设计

电子平台的安全模式设计

1.       前言

　  由于电子平台的办公信息的敏感性以及网络的虚拟性和开放性，决定了电子平台系统需要有强有力的用户访问安全、网络安全、系统安全、应用程序安全、数据库和事务管理器安全来保证电子平台系统的安全。而系统采用J2EE框架正是满足以上需要，它不但将安全任务的一些内容转移给容器，且能够提供应用程序员完成安全任务的功能。

2.       方案的整体设计

在电子平台系统的安全体系中我们主要应用到了集中认证、系统密码加密、Web模块的角色配置和EJB模块的角色配置。下面就是系统的整个安全体系的设计示意图：

电子平台安全体系示意图

2.1   集中认证：

集中认证就是采用CA机构的认证服务器和Web应用程序，对客户端数字证书的验证过程与普通的认证相同都是采用的Https传输信息。在验证完成以后CA机构的Web应用程序会根据配置文件转发到指定位置，这里我们可以设定电子平台系统的首页面，同时将认证的一些信息放到客户端的Cookie中，这样我们只需要在自己的电子平台系统的用户进行业务登入的时候调用CA机构提供的认证接口进行验证，这个过程是采用Http方式，速度上将会有很大的提高，同时保证的安全性，且对电子平台系统的影响较小，有利于系统的开发、集成和更新。为了更好的说明集中认证与普通认证的区别，我做了以下比较：如图

                           集中认证VS普通认证

            下面我们集中讨论集中认证在电子平台系统的应用，下面是电子平台系统应用集      中认证的一个网络流程示意图和集中认证的程序流程图：

                                                        电子平台应用集中认证的流程图

       系统应用集中认证登陆注册的程序流程：

  上面提到的一些关于集中认证的一些概念可以参考《关于CA的一些基本概念》和《公钥基础设施PKI技术》。具体服务证书和CA认证机构auth.war包怎么部署以及如何应用参考《集中认证在电子平台中应用》文档。关于调用CA机构提供的验证接口在LoginAction/RegAcion内进行。具体如何实施在下面的“系统开发过程中注意的事项”中会具体讨论。

2.2       J2EE安全体系：

       电子平台采用采用先进的、流行的MVC三(多)层技术体系架构，分别为：View、Controller、Model，如下图所示：

       这样将业务逻辑层与视图分开不但有利于开发而且保证了数据的安全性，下面主要谈一下J2EE应用程序的安全性。

J2EE应用程序安全使用基于角色的安全机制，在开发期间，我们应当通过为特定的安全角色分配安全资源和方法来确定应用程序的安全策略。在应用程序装配期间，安全角色被影射为真实的用户和组。这种两段式安全管理方法给予应用程序很大的灵活性和可移植性，在运行时，J2EE容器负责强迫执行访问控制安全的资源和方法。J2EE容器支持两类安全：

       ·说明性的安全性：

           ·可编程的安全性：

      说明性的安全性，根据名称可以看出说明性安全主要是将安全策略在部署的描述文件中定义，可编程的安全性要求程序员通过编码来保证J2EE的安全性。而不需编码实现，它主要借助J2EE的容器根据定义对安全策略。可编程的安全性，我们在本系统中采用说明性的安全性。两者之间都有各自的优缺点：

名称	优点	缺点
说明性的安全性	不需要编码，减轻了程序员的编码工作量；更改角色方便。	灵活性差；部署的时候比较麻烦
可编程的安全性	灵活性好，能够根据业务的需要定制安全；部署方便	需要编码实现，增加了程序员的工作量；更改角色不方便，需要修改代码

  在电子平台项目中我们是尽量采用说明性的安全性，若在说明性的安全性无法满足业务                  需求的情况下采用可编程的安全性。下面我们分为Web模块和EJB模块来讨论：

2.21：Web模块：

在Web模块里面用的角色现拟如下：

大众用户               everyone

企业用户               enterprise

质检用户               organ

市监督局               city_surveillance

省监督局               province_ surveillance

国家监督局            country_ surveillance

平台管理员            plat _manager

具体到开发部署的时候可以根据需要变通的进行更改和增删。

（A）定义验证方法：

        验证机制定义客户如何被Web应用程序验证。在应用任何验证约束之前，用户需要使用一个已经设置的机制来通过验证过程。Servlet规范定义了4种验证用户的机制。基础验证、摘要验证、客户证书验证、基于表单的验证。电子平台系统主要采用了客户端证书验证和基于表单的验证。其中关于证书的验证采用的集中认证的模式。

（B）定义安全角色：

        在Web部署描述文件web.xml中，所用在Web模块中使用的安全角色和一个可选的描述文字都必须被命名。一个角色时一个占位符，在应用程序的部署期间占位符最后被映射为真实的用户和用户组。

（C）定义安全约束：

        在Web模块中可以定义多个安全约束。安全约束声明了应用程序的内容是如何被保护的。对于一个给定的安全约束，我们定义2个特征：

·Web资源集合：一个Web资源集合是一组URL模式和该模式代表的资源中的HTTP方法。一个安全约束可以有多个Web资源集合。

·授权约束：一个授权约束定义了在安全约束下授权哪些角色存取Web资源集合。

（D）为单个的servlet/jsp定义安全角色引用（可选）：

        这部分内容可以根据需要，将一些比较特殊而且安全级别比较高的页面定义安全角色引用。

（E）口令加密：

       口令加密采用最为常用的MD5, MD5的全称是Message-Digest Algorithm 5，在90年代初由MIT的计算机科学实验室和RSA Data Security Inc发明，经MD2、MD3和MD4发展而来。

 Message-Digest泛指字节串(Message)的Hash变换，就是把一个任意长度的字节串变换成一定长的大整数。请注意我使用了“字节串”而不是“字符串”这个词，是因为这种变换只与字节的值有关，与字符集或编码方式无关。

MD5将任意长度的“字节串”变换成一个128bit的大整数，并且它是一个不可逆的字符串变换算法，换句话说就是，即使你看到源程序和算法描述，也无法将一个MD5的值变换回原始的字符串，从数学原理上说，是因为原始的字符串有无穷多个，这有点象不存在反函数的数学函数。

 MD5的典型应用是对一段Message(字节串)产生fingerprint(指纹)，以防止被“篡改”。举个例子，你将一段话写在一个叫readme.txt文件中，并对这个readme.txt产生一个MD5的值并记录在案，然后你可以传播这个文件给别人，别人如果修改了文件中的任何内容，你对这个文件重新计算MD5时就会发现。如果再有一个第三方的认证机构，用MD5还可以防止文件作者的“抵赖”，这就是所谓的数字签名应用。

2.22：Web Service模块

   这部分内容还有待完善。

2.23：EJB模块：

   EJB是执行应用程序的业务逻辑的J2EE组件。它是一般用于访问敏感的数据。这样，为EJB指派恰当的策略是非常重要的。

   访问控制应用于单独的会话和实体bean方法，所以只有属于特定安全角色的调用这些方法。会话、实体和消息驱动bean方法在调用者（EJB服务器）的身份下或者一个特定的安全角色下被委托执行。这称为委托策略（Delegation Policy）或者成为以他人身份运行模式映射（Run-As Mode Mapping）。下面主要就我们电子平台的Ejb模块在WSAD上设置安全性的过程。

（1）说明性的安全性：J2EE 部署描述文件ejb-jar.xml 包含了EJB 的安全视图，也包含了Bean 类的结构化和参考的信息。一个安全视图包含一个逻辑安全角色的集合。执行声明方式的授权一般分两步,首先声明Bean 的安全策略，即声明受保护的Bean 方法的许可，然后为部署员声明安全角色。

（2）可编程的安全性：因为并非所有的安全策略都可以用声明的方式表达，EJB体系结构允许通过使用javax.ejb.EntityContext接口的isCallerInRole (String roleName) 和getCaller-Principal()方法提供了一种对一个调用者安全上下文的可编程访问的方式。安全上下文的作用使得所有的安全检查成为可能，安全上下文环境将当前调用者的安全状态封装起来，在应用程序代码中看不到安全上下文环境，由EJB容器在后台直接使用它们，通过隐含的方式在Stub 和Skeleton 程序中传递安全上下文环境，将安全信息传播出去。

（A）定义安全角色

       所用在EJB中使用的安全角色都必须在EJB模块的部署描述文件ejb-jar.xml                 中命名。每个名字可以有可选的描述文字。一个角色就是一个占位符，在部署应用              程序时，角色映射为真正的用户和用户组。

（B）指派方法许可

       会话和实体bean的方法可以通过给特定角色指派适当的许可来保证安全。方                 法许可在EJB部署描述文件ejb-jar.xml中定义

（C）为未保护的方法指派角色

       在应用程序安装期间，对于那些没有在部署描述文件中显式保护的会话和实体EJB           方法可以使用IBM Websphere 应用服务器管理控制太指定其方法许可。这些未保护的          方法能用下列许可中的一种：

·不选（Uncheck）：本许可是默认选项。这表明任何人都可以调用这些方法。

·排斥（Exclude）：没有人可以调用这些未保护的方法。

·角色（Role）：只有指定的安全角色的成员才可以调用这些未保护的方法。

（D）管理委托策略

      当一个EJB调用另一个EJB的方法时，默认情况下，第一个EJB调用者的身份传             播到第二个EJB。在这个方式下，在调用链上的所有EJB方法都可以看到同样的基本信           息。然而，在一些情况下，一个EJB需要用到一个预先定义好的身份，例如一个给定角        色成员，来调用另一个EJB方法。一个例子就是一个消息驱动bean的onMessage()               方法，该方法调用会话bean的protected方法。消息驱动bean的onMessage()方                法被没有调用者角色的容器调用，这样，该方法就不能调用会话bean的protected方          法。通过委托onMessage()方法作为一个特定角色来运行，然后把该角色加入到受保            护的会话bean方法的访问许可中，这样onMessage()方法将能访问到被保护的方法。

（E）bean级委托

       EJB2.0规范中定义了使用<run-as>元素可以在EJB bean级委托，这将允许应             用程序装配者委托一个给定bean的所有方法作为一个指定安全角色的成员运行。在部              署时，作为指定安全角色的一个真实用户必须通过一个称为run-as的角色映射进程映               射到这个角色。被委托的bean将使用被映射的用户身份调用其它EJB。

（F）方法级委托

       除了EJB2.0规范中定义的bean级的委托策略之外，IBM Websphere应用服务                 器还提供了执行方法级的EJB委托能力。这与bean级委托是一样的，不过他可以应用        于指定的EJB方法，而不是作为一个整体的bean。这个委托的粒度更细，它允许应用               程序装配者（集成者）为同一个EJB的不同方法委托不同的安全角色。

      另外，方法级的委托提供一个额外的委托选项：作为服务器运行。这个选项表明该           方法使用应用服务器的身份来调用其它的EJB。

（G）定义安全角色引用（可选）

       安全角色引用提供在EJB的Java代码中命名的安全角色和在应用程序装配期间定      义的安全角色之间的间接层。该间接层允许更改安全角色名称，而无须改变任何应用程              序的代码。

3.       系统开发过程中注意的事项

3.1   如何调用信诚通提供的验证接口

       由于在配置认证服务器的时候，还有些问题没有解决，于是我们采用了一种变通的方式，还是应用信诚通提供的Web应用程序，但是在此基础上修改了一下，由原来的要通过认证服务器来验证证书的合法性，改为利用代码来验证。利用编码来验证证书是否由信诚通签署，有效期是否失效等，这个方法仅仅在我们测试阶段应用，具体到交付项目并进行正式发布的时候在采用信诚通的集中认证，利用他们的认证服务器来对证书验证。在电子平台系统应用到信诚通提供的接口的地方主要有2个地方：

      

评论

1 楼 gdwrx_winson 2011-01-17  

图片看不到......