日期
|
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
个地方:
3.11
登录的
Action
中
具体实现代码参考
QiYeLoginAction
和
JiGouLoginAction
。
3.12
注册的
Action
中
具体实现代码参考
QiYeRegAction
。
3.2
如何开发
Web
模块说明性的安全
安全角色映射图
3.21
基于表单验证的开发方法
这部分在用
struts
的前台
validator
验证和后台
action
对用户的合法性进行验证。
Validator
对用户名和密码是否完整输入,长度是否合法等等进行简单的判定,在通过
validator
的验证后才将数据提交给
action
做后台的处理。不但防止了客户端恶意的提交,且保证了数据的合法性,有利于提高服务器的性能。这部分开发方式同我们经常做的客户登录验证方法一样,但是要注意的是,在
action
里面对用户名和密码验证的同时要对客户端的
tokenID
进行验证,也就是要调用
CA
机构为我们提供的集中认证的接口。我们在开发的时候采用如下验证逻辑:首先从
request
中得到
cookie
数组对象,通过循环得到
tokenID
的值,然后调用
authzPrn.authzPrnPrivilege(tokenid, "", request.getRemoteAddr())
得到
PrnProperty
对象。其中要对
cookie
、
tokenID
、
PrnProperty
是否为
null
,做判断只有在
PrnProperty
不为
null
的时候,也就是认证通过的时候再对用户名和密码进行验证。这部分代码可以参考标签二的
QiYeLoginAction()
和
JiGouLoginAction()
。在具体开发的时候我可以负责登录和注册部分。其它地方均不要调用这个接口。
3.32
为
Web
组件定义安全角色的开发
在
2.21
部分我们已经初步为
Web
组件定义了几个角色,这就要求我们要将对应的
web
组件放到对应的文件夹里面。用户在访问的时候会根据角色的不同来确定是否具有访问某个文件夹里面的页面的权限。所以这就要求我们在做前台开发的时候要根据页面服务的对象放到各自的文件内,而不能够随意放置。同时最好将
web
组件模块化,没有特别的需要不要跨模块访问页面。
下面主要介绍如何在
wasd
和
was
中设置
web
的安全角色:
(A)
安全角色的定义
打开
web
的部署描述符:如图
点击“安全性”单击“添加”新增一个安全角色。命名这个角色的名称,不妨我们命名为“
manager
”,在描述的筐内增加一些说明性的文字。同样方法可以按照业务的需要新增其他的角色。
(B)
设置安全约束
在“安全角色”定义好以后,保存。进入“安全约束”的设定,点击“安全约束”选项,进入“安全约束”界面,如图:
点击“添加”输入现实名称,在“
web
资源集合”部分,单击新增
出现如上一个窗口,输入相应的文字,选择
http
方法,可以选择
get
和
post
点击添加,
URL
模式可以有如下通配符“
/*
”、“
/*.jsp
”、“
/
”等等。确定。一个安全约束可以有多个
web
资源集合。点击“授权角色”的编辑,
选中要授权的用户的角色,出现的角色就是我们刚才定义的角色。确定。同样的方法可以新增其他的约束。
完成后,保存!
Web
的安全角色的定义和配置已经完成,下面的工作是我们在部署的时候,将这些角色映射到系统的实际用户。
倒入项目为
XX.ear
形式,下面就讨论如何在
was
上部署项目,并经
web
的安全角色映射到实际的用户:
1、
启动
was
服务器
2、
登陆管理控制台
3、
安装企业应用程序
上面上个步骤不再一一赘述,按照相关的提示进行即可。需要注意的几个地方,要将
web
表述文件中定义的安全角色映射为实际的用户,如图:
可以通过查找用户或者用户组进行添加和修改。如下图:
下面我们主要讨论设置
web
的安全性
4、
启动全局安性
在进行全局安全性设置之前,我们先认识几个术语以及他们的意义:
(1)
用户注册表
·
LocalOS
:
Websphere
认证机制可以使用本地操作系统的用户帐户数据库。
WebSphere Application Server
提供
Windows NT
和
Windows 2000
的本地帐户注册表和域注册表的实现,以及
Linux
、
Solaris
和
AIX
用户帐户注册表的实现。要求:
·
对于单机机器,用户应该:
o
是管理组的成员。
o
应该拥有作为操作系统的部件操作特权。
o
应该拥有登录为服务特权(如果服务器作为服务运行的话)。
·
对于是域成员的机器,仅域用户可以启动服务器进程且必须是:
o
域控制器中域管理组的成员。
o
应该在域控制器上的域安全策略中拥有作为操作系统的部件操作特权。
o
应该在本地机器上的本地安全策略中拥有作为操作系统的部件操作特权。
o
应该在本地机器上拥有登录为服务特权(如果服务器作为服务运行的话)。
注
:
用户是域用户而不是本地用户,这暗示着当机器是域的一部分时,仅域用户可以启动该服务器。
·
对于域控制器机器,用户应该是:
o
域控制器中域管理组的成员。
o
应该在域控制器上的域安全策略中拥有作为操作系统的部件操作特权。
o
应该在域控制器上拥有登录为服务特权(如果服务器作为服务运行的话)。
由于我们做开发的机器均不是域用户,故做开发的时候我们采用单机的本地
OS
·
LDAP
:
轻量级目录访问协议(
LDAP
)是一个用户注册表,它使用
LDAP
绑定执行认证。
WebSphere Application Server
安全性提供和支持多数主
LDAP
目录服务器的实现,其可以用作用户和组信息的库。产品进程(服务器)调用的这些
LDAP
服务器是用于认证用户和其它相关任务(例如,获取用户或组信息)的安全性。此支持通过使用不同的用户和组过滤器提供以获取用户和组信息。这些过滤器具有一些缺省值,您可以修改这些缺省值来适应您的需要。另外,定制
LDAP
功能部件允许您通过使用适当的过滤器为他们的用户注册表使用任何其它的
LDAP
服务器(它不在
LDAP
服务器的产品支持列表中)。
要将
LDAP
用作用户注册表,您需要知道有效的用户名(标识)、用户密码、服务器主机和端口、基本专有名称(
DN
)并且若有必要绑定
DN
和绑定密码。您可以选择可搜索注册表中任何有效用户。在某些
LDAP
服务器中,管理用户是不可搜索并无法被使用的(例如,
SecureWay
中的
cn=root
)。此用户指的是文档中的
WebSphere Application Server
安全性服务器标识、服务器标识或服务器用户标识。作为服务器标识意味着用户在调用某些受保护的内部方法时具有特殊特权。通常,一旦打开安全性后,此标识和密码用于登录管理控制台。如果那些用户是管理角色的一部分,则您可使用其它用户。
当在产品中启用安全性时,产品启动期间此服务器标识和密码由注册表认证。如果认证失败,服务器无法启动。重要的是选择未到期或者经常更改的标识和密码。如果需要在注册表中更改产品服务器用户标识或密码,确保在所有产品服务器启动并正在运行时执行更改。一旦在注册表中完成更改后,使用
配置
LDAP
用户注册表
中描述的步骤。更改标识、密码和其它配置信息,保存、停止并重新启动所有服务器,这样供产品使用新的标识或密码。如果在启用了安全性的情况下启动产品时遇到任何问题,在服务器可以启动之前禁用安全性(要避免这种情况的发生,确保此面板中的任何更改在
“
全局安全性
”
面板中得到确认)。一旦服务器启动,您就可以更改标识、密码和其它配置信息然后启用安全性。
·定制:本系统不采用这种方案
(2)
认证机制
·
SWAM
:
简单
WebSphere
认证机制(
SWAM
)用于简单的、非分布式、单应用程序服务器运行时环境。单应用程序服务器限制是由于
SWAM
不支持
forwardable
凭证所致。如果应用程序服务器进程
1
中的
servlet
或企业
bean
调用另一个应用程序服务器进程
2
中的企业
bean
上的远程方法,则进程
1
中的调用者身份不发送到服务器进程
2
。发送的是未认证的凭证,根据
EJB
方法上配置的安全性许可权,可能会导致授权失败。
由于
SWAM
用于单应用程序服务器进程,因此不支持单次注册(
SSO
)。
SWAM
认证机制适合于简单环境、软件开发环境或其它不需要分布式安全性解决方案的环境。我们在做开发的时候采用这种方案。
·
LTPA
:
轻量级第三方认证(
LTPA
)用于分布式、多应用程序服务器和机器环境。它支持可转发的凭证和单次注册(
SSO
)。
LTPA
通过密码术可支持分布式环境中的安全性。此支持允许
LTPA
进行加密、数字签署和安全地发送认证相关的数据,并在以后解密和验证该签名。
轻量级第三方认证(
LTPA
)协议允许
WebSphere Application Server
提供使用密码术的分布式环境中的安全性。多个节点和单元中分布的应用程序服务器可以使用此协议安全地通信。它也提供单次注册(
SSO
)功能部件,在那里仅需要在域名系统(
DNS
)域中认证用户一次,并且用户可以访问其它
WebSphere
单元中的资源而不必获取提示。此协议使用加密密钥(
LTPA
密钥)加密和解密在服务器间传递的用户数据。这些密钥需要在不同的单元间共享,这是为了一个单元中的资源能够访问其它单元中的资源(这假设涉及的所有单元都使用相同的
LDAP
或定制注册表)。
当使用
LTPA
时,用用户信息和它到达的到期时间创建令牌,并由密钥签署。
LTPA
令牌是对时间敏感的。所有参与保护域的产品服务器都必须有它们的时间、日期和同步的时区。如果没有,那么
LTPA
令牌过早出现到期并导致认证或确认失败。然后此令牌传递给其它服务器(在同一个单元或不同的单元中),通过
cookie
(对于启用
SSO
时的
Web
资源)或通过认证层(企业
bean
的安全性认证服务(
SAS
)或公共安全互操作性
V2
(
CSIv2
))。如果单个或多个接收服务器正在与源始服务器共享相同的密钥,那么可以解密令牌以获取用户信息,然后验证这些用户信息以确保它没有到期并且令牌中的用户信息在它的注册表中是有效的。成功验证后,在授权检查后可访问接收服务器中的资源。
所有单元(单元、节点、应用程序服务器)中的
WebSphere Application Server
进程共享相同的密钥集。如果不同的单元间需要密钥共享,则从一个单元导出它们并将其导入另一个单元。出于安全性考虑,导出的密钥使用用户定义的密码加密。在将密钥导入另一个单元时,需要这个相同的密码。
LTPA
是在
WebSphere Application Server
的
Network Deployment
版本中唯一受支持的机制。在
WebSphere Application Server
的
Base
版本中,
LTPA
和简单
WebSphere
认证机制(
SWAM
)都受支持。当在带有
LTPA
的
WebSphere Application Server Network Deployment
或
Base
产品中首次启用安全性时,配置
LTPA
通常是执行的初始化步骤。
LTPA
要求配置的用户注册表是中央共享的库,如同
LDAP
或
Windows
域类型注册表,以致于用户和组是相同的而不考虑机制问题。
下表概述认证机制能力和
LTPA
可以使用的用户注册表。
|
可转发的凭证
|
SSO
|
LocalOS
用户注册表
|
LDAP
用户注册表
|
定制用户注册表
|
SWAM
|
No
|
No
|
Yes
|
Yes
|
Yes
|
LTPA
|
Yes
|
Yes
|
Yes
|
Yes
|
Yes
|
以后实际部署的时候采用
LTPA
。
下面是就上面谈论到的用户注册表和认证的机制如何在
websphere
中如何设置进行讨论:
(1)
用户注册表
·
LocalOS
:
此任务的步骤
1.
在管理控制台左侧导航面板中单击安全性
>
用户注册表
>
本地
OS
。
2.
在服务器用户标识字段中输入有效用户名。
3.
在服务器用户密码字段中输入用户密码。
4.
单击确定。重新启动服务器。
用户和密码的验证在此面板中未发生。仅当您在
“
全局安全性
”
面板中单击确定或应用时才进行验证。如果您处于第一次启用安全性的进程中,完成其它步骤,并转至
“
全局安全性
”
面板,以确保本地
OS
是
“
活动用户注册表
”
。如果安全性已启用,而您已在此面板中更改用户或密码信息,则确保转至
“
全局安全性
”
面板,并单击确定或应用以验证更改。如果您的更改未验证,则服务器可能无法启动。
·
LDAP
:
此任务的步骤
1.
在管理控制台中,在左侧导航面板单击安全性
>
用户注册表
> LDAP
。
2.
在服务器用户标识字段中输入有效用户名。根据高级
LDAP
设置面板中的用户过滤器定义,您可以输入用户的完整专有名称(
DN
)或用户的缩写名。例如,对于
Netscape
输入用户标识。
3.
在服务器用户密码字段中输入用户的密码。
4.
从类型列表中选择使用的
LDAP
服务器类型。
LDAP
服务器的类型确定
WebSphere Application Server
所使用的缺省过滤器。当这些缺省过滤器更改时,类型字段更改为定制,其表明使用定制过滤器。一旦您单击高级
LDAP
设置面板中的确定或应用后,此操作发生。从列表选择定制,如果需要,修改用户和组过滤器,以使用其它
LDAP
服务器。如果选择
IBM Directory Server
或
iPlanet Directory Server
,则还选择忽略大小写字段。
5.
在主机字段中输入
LDAP
服务器的全限定主机名。
6.
在端口字段中输入
LDAP
服务器端口号。主机名以及端口号表示
WebSphere Application Server
单元中此
LDAP
服务器的域。因此,如果不同单元中的服务器使用轻量级第三方认证(
LTPA
)令牌互相通信,则这些域必须在所有单元中完全匹配。
7.
在基本专有名称字段中输入基本专有名称(
DN
)。基本
DN
表明在此
LDAP
目录服务器中用于搜索的开始点。例如,对于
DN
为
cn=John Doe, ou=Rochester, o=IBM, c=US
的用户,指定基本
DN
为下列任何一种(假设后缀为
c=us
):
ou=Rochester, o=IBM, c=us
或
o=IBM c=us
或
c=us
。此字段可区分大小写,而且建议它们在目录服务器中匹配大小写。此字段是除
Domino Directory
外所有
LDAP
目录所必需的。
“
基本
DN”
字段对于
Domino
服务器来说是可选的。
8.
如果需要,在绑定专有名称字段中输入绑定
DN
名。如果在
LDAP
服务器上不可能执行匿名绑定,则需要绑定
DN
来获取用户和组信息。如果
LDAP
服务器设置为使用匿名绑定,则保留此字段为空白。
9.
如果需要,在绑定密码字段中输入相应于绑定
DN
的密码。
10.
如果需要,修改搜索超时值。此超时值是
LDAP
服务器在放弃请求前等待发送响应到产品客户机的最大时间数。缺省值是
120
秒。
11.
仅当您使用路由器将请求散布到多台
LDAP
服务器,并且路由器不支持亲缘关系时,才禁用重用连接字段。为所有其它请求,保留此字段为启用。
12.
如果需要,启用忽略大小写标志。当启用时,授权检查不区分大小写。通常,授权检测涉及检查用户的完整
DN
(其在
LDAP
服务器中是唯一的),并区分大小写。然而,当使用
IBM Directory Server
或
iPlanet Directory Server LDAP
服务器时,此标志需要启用,这是因为从
LDAP
服务器获取的组信息在大小写方面不一致。此不一致仅影响授权检查。
13.
如果与
LDAP
服务器的通信是通过
SSL
的,则启用单个套接字层(
SSL
)。要获得有关为
SSL
设置
LDAP
的更多信息,请参阅
为
LDAP
客户机配置
SSL
。
14.
如果启用
SSL
,从
SSL
配置字段中的列表选择适当的
SSL
别名配置。
15.
单击确定。
此面板中不发生用户、密码和设置的验证。仅当您在全局安全性面板中单击确定或应用时才进行验证。如果您是第一次启用安全性,完成剩余的步骤,并转至全局安全性面板。选择
LDAP
作为活动用户注册表。如果安全性已启用,但是此面板上的信息已更改,则转至全局安全性面板,并单击确定或应用验证您的更改。如果您的更改未验证,服务器可能无法启动。
(2)
认证机制
·
SWAM
:
正如前面所讲的,
SWAM
是针对简单的非分布式的单个应用服务器运行时环境设计的。之所以只能是单个应用服务器,主要是因为
SWAM
不能传递凭证。
在
IBM Websphere
应用服务器上使用
SWAM
不需要特别的配置。只需要在全局安全性页面上选择
SWAM
作为验证机制即可。
·
LTPA
:
在第一次设置安全性时,初始执行此任务需要下列步骤。
此任务的步骤
1.
在左侧的导航面板中单击安全性
>
认证机制
> LTPA
。
2.
在密码字段中输入密码,并确认它。此密码用于在导出和导入密钥期间,加密
和解密
LTPA
密钥。记住此密码,因为将密钥从此单元导出到另一个单元时,您需要再次输入它。
3.
在超时字段中输入正整数值。此超时值是指
LTPA
令牌有效的时间(以分钟计)。令牌包含此到期时间,以便接收此令牌的任何服务器可在进一步处理前,确保此令牌有效。当令牌到期时,提示用户登录。此字段的理想值取决于您的配置。缺省值为
30
分钟。
4.
单击应用或确定。现在,已设置
LTPA
配置。此步骤中您不应该生成
LTPA
密钥,因为它们会在以后自动生成。剩余步骤的处理需要启用安全性,从
SSO
开始(如果需要
SSO
)。
本系统不需要!
5.
完成
“
全局安全性
”
面板中的信息,并按
“
确定
”
。当在
“
全局安全性
”
面板中单击确定或应用时,
LTPA
密钥第一次自动生成,因此,您不应该手工生成密钥。
3.3
如何开发
Web
模块编程性的安全
这部分实在说明性的安全模式无法满足需求的情况下采用,先暂时不管!
3.4
如何开发
EJB
模块说明性的安全
这部分内容有待增加!
3.5
如何开发
EJB
模块编程性的安全
这部分实在说明性的安全模式无法满足需求的情况下采用,先暂时不管!
4.
总结
以上是我的初步设计方案,还有部分内容有待补充完善。由于以前没有参与过
J2EE
安全体系的设计工作,且电子平台对安全系统这块的要求比较高等原因,在本设计方案中肯定有很多不足和错误之处,敬请同仁们批评指正,以更加完善整个系统的安全体系,为我们的后期开发工作打下良好的铺垫。
5.
参考文献
主要参考文献如下:
《
IBM WebSphere Studio J2EE
应用开发》
Howard Kushner
主编
《
WebSphere V5.0
安全手册》
(IBM
红皮书
)
《
WebSphere Application Server V5.0
系统管理和配置》
(IBM
红皮书
)
《
WebSphere V6.0
安全手册》
(IBM
红皮书
)
IBM Websphere
信息中心
IBM
中国技术论坛