日期
|
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
个地方: