解析J2EE中的安全问题

　　现在越来越多的企业应
的框架和服务的支持.j2ee
等)。本文将介绍j2ee提供
然后结合具体的实例向读者
基于j2ee1.3版本的。

用构建在j2ee平台上，这得益于
为企业应用提供了多方面的服务
的安全服务。首先介绍j2ee中的
展示如何在程序中应用j2ee提供

j2ee为企业应用的开发提供了良好
(Security、Transaction、Naming
安全概念和j2ee的安全体系架构，
的安全特性。本文所介绍的内容是

　　j2ee中的安全概念

　　主体（Principal）：
Principal）用主体名作为
名就是用户的登陆名，验证
用怎样的认证方法，因此主

主体（Principal）是被在企业
它的标识，通过与主体相关的验
数据就是登陆的密码。J2EE规范
体名和验证数据的内容和格式依

安全服务验证了的实体。主体（
证数据进行验证。通常情况下主体
中并没有限定J2EE 产品提供商使
不同的认证协议而不同。

　　安全策略域（Security
是一个逻辑范围或区域，在
它是从安全策略的角度划分
伙伴等不同的安全域，对这

Policy Domain）：也称安全域
这一范围或区域中安全服务的管
的区域。比如可以将企业应用系
些安全区域采用不同的安全策略

（security domain）或realm，它
理员定义和实施通用的安全策略。
统划分为企业员工、供应商、合作
。

　　安全技术域（Security Technology
个安全技术域中使用同样的安全机制来执
域。

Domain）：它是从安全技术的角度划分的区域，在一
行安全策略。一个安全技术域可以包括多个安全策略

　　安全属性（Security Attributes）
全属性。安全属性可用来访问被保护的资
。J2EE产品提供商或具体的验证服务的实
规范并没有限定什么样的安全属性将与主

：每个主体（Principal）都有一系列与之相关的安
源，检查用户的身份和完成其他一些安全相关的用途
现来决定怎样将安全属性与一个主体联系起来。J2EE
体相联系。

　　凭证（Credential）：
。如果成功的通过了验证，
也可能获取另一个主体的凭

凭证包含或引用为J2EE系统验证
主体将获得一个包括安全属性的
证。在这种情况下两个主体在同

一个主体的验证信息（安全属性）
凭证。如果被允许的话，一个主体
一安全域中具有相同的安全属性。

　　j2ee的安全体系结构

　　1．基于容器的安全

　　在j2ee的环境中，组件的安全是由他
用或者很少在组件中添加有关安全的代码
业级应用系统有更好的灵活性和扩展性。
两种形式的基于容器的安全性－说明性的

们各自的容器来负责的，组件的开发人员几乎可以不
。这种安全逻辑和业务逻辑相对独立的架构，使得企
J2ee规范要求j2ee 产品必须为应用程序开发者提供
安全性和可编程的安全性。

　　● 说明性的安全性

　　说明性的安全性通过安
安全角色，访问控制和验证
。部署描述符是组件开发者
开发者用它来表示应用中的
境中的用户和组映射起来。

全结构描述的方式来代表应用程
要求等。在j2ee平台中部署描述
和应用程序部署者或应用程序组
安全需求，应用程序部署者或应

序的安全需求，安全结构一般包括
符充当了说明的安全性的主要工具
装者之间的交流工具。应用程序的
用程序组装者将安全角色与部署环

　　在程序运行时容器从部
全验证。说明的安全性不需
符来完成的。

署描述符中提取出相应的安全策
要开发人员编写任何安全相关的

略，然后容器根据安全策略执行安
代码，一切都是通过配置部署描述

　　● 可编程的安全性

　　可编程的安全性在说明
的API来对安全作出决断。
的。J2ee在EJB EjbConext
个方法：

性的安全性的基础上，使安全敏
这在说明性的安全性不足以满足
interface和servlet HttpServl

感的应用可以通过调用被容器提供
企业的安全模型的情况是非常有用
etRequest interface中各提供两

　　isCallerInRole (EJBContext)

　　getCallerPrincipal (EJBContext)

　　isUserInRole (HttpServletRequest)

　　getUserPrincipal (HttpServletRequest)

　　这些方法允许组件根据调用者或远程
将有这些方法的详细介绍和例程，以便读
模型

用户的安全角色来作出商业判断。在文章的后面部分
者更好的理解可编程的安全性的用途。 J2ee的验证

　　身份验证是用户或组件调用者向系统
证信息（通常是用户名和密码或者是用户
安全策略来验证用户的身份。

证明其身份的过程。用户通过某种方式向系统提交验
的数字证书），系统用用户提供的验证信息和系统的

　　● 用户的验证

　　用户的验证根据其客户
验证

端类型不同分为两种：Web 客户

端的验证和Application客户端的

　　a. Web 客户端的验证

　　Web客户端通常通过htt
、jsp（java server page
境中，企业的某些资源往往
此对企业中各种web资源进
化的需求，j2ee提供了三种

p协议来请求web服务器端的资源
）文件、java servlet和其他一
要求只允许某些人访问，有些资
行访问控制是十分必要的。为了
基于web客户端的验证方式：

，这些web资源通常包括html网页
些二进制或多媒体文件。在企业环
源甚至是机密的或安全敏感的。因
满足企业中的不同安全级别和客户

　　● HTTP基本验证（HTTP Basic Authentication）

　　HTTP基本验证是HTTP协议所支持的
为验证信息。Web客户端从用户获取用户
指定的区域（realm）中验证用户。但需
验证方法并不对用户密码进行加密，而只
务器对用户来说也是非验证过的。不能保
以采用一些安全措施来克服这个弱点。例
VPN技术。

验证机制。这种验证机制使用用户的用户名和密码作
名和密码，然后传递他们给web服务器，web服务器在
要注意的是，这种验证方法是不够安全的。因为这种
是对密码进行基本的base64的编码。而且目标web服
证用户访问到的web服务器就是用户希望访问的。可
如在传输层上应用SSL或者在网络层上使用IPSEC或

　　● 基于表单的验证（Form-Based Authentication）

　　基于表单的验证使系统
本HTTP的验证方法的唯一区
验证方法同样具有与基本HT
后密码以明文形式在网路中
容易就可以获取用户的密码
确定这两种方式的弱点对你

开发者可以自定义用户的登陆页
别就在于它可以根据用户的要求
TP验证类似的不安全的弱点。用
传递，如果在网路的某一节点将
。因此在使用基本HTTP的验证方
的应用是可接受的。

面和报错页面。这种验证方法与基
制定登陆和出错页面。基于表单的
户在表单中填写用户名和密码，而
此验证请求截获，在经过反编码很
式和基于表单的验证方法时，一定

　　● 基于客户端证书的

验证（Client-Certificate Aut

hentication）

　　基于客户端证书的验证方式要比上面
保证验证的安全性。安全套接层（Secure
器端认证，信息真实性等方面的安全保证
你可以把这个公钥证书看作是你的数字护
构（CA）－一个被信任的组织颁发的。这
准。如果你指定了这种验证方式，Web服
。

两种方式更安全。它通过HTTPS（HTTP over SSL）来
Sockets Layer）为验证过程提供了数据加密，服务
。在此验证方式中，客户端必须提供一个公钥证书，
照。公钥证书也称数字证书，它是被称作证书授权机
个数字证书必须符合X509公钥体系结构（PKI）的标
务器将使用客户端提供的数字证书来验证用户的身份

　　b. 应用程序客户端的

验证（Application Client Use

r Authentication）

　　java客户端程序是执行在用户本地ja
户可通过java.exe或javaw.exe直接启动
也拥有main方法，但他们在运行时存在一
运行在自己的容器中。用户通过容器来执
器就有机会在J2ee应用程序客户端被执行
的方式来获取用户的验证信息。可以选择
序的用户的验证信息，也可以选择自定义
，应用程序开发者必须提供一个实现了ja
interfce的类,并且在j2ee部署描述文件a
中加入这个类的类名。这样，当系统需要
中的CallbackHandler实现类的类名传递
这个实现类。这个类的实例负责收集用户
块，登陆模块用这些验证信息来验证用户
用户输入来收集用户验证信息，也可以是
本地或在线的用户证书库来获取用户的电

va虚拟机上的java程序，它拥有main方法，通常由用
执行。J2ee应用程序客户端与java客户端程序相似，
定的差别。J2ee应用程序客户端和其他j2ee组件一样
行J2ee应用程序客户端。这样J2ee应用程序客户端容
之前完成用户身份的验证。J2ee提供了一种可自定义
使用容器提供的缺省的方式来获取j2ee应用客户端程
的方式来获取用户的验证信息。当选择自定义方式时
vax.security.auth.callback.CallbackHandler
pplication-client.xml中的元素callback-handler
验证用户身份时，客户端程序的容器将部署描述文件
给系统的登陆模块（验证模块），登陆模块再实例化
验证信息，并将收集到的用户验证信息传递给登陆模
。这个实现类可以是具有用户界面的，或是通过要求
通过命令行来获取用户验证信息，还可能是通过读取
子证书。选取哪种方式取决于验证信息的存储方式。

　　有些j2ee产品厂商把容
务集成起来，从而在一定的

器的验证服务和本地系统的验证
应用系统的范围内实现单点登陆

服务或其他应用系统产品的验证服
的能力。

　　● 单点登陆（Single Sign-On）

　　单点登从用户的视角是
此逻辑安全区域中不同应用
陆。这种能力对多种IT应用
提高，企业中的应用系统也
，这些安全策略典型的包括
由于各系统互相独立，一个
统登陆。这对于用户来说必
对于这种情况，单点登陆的
J2ee1.3也在规范中建议j2e
规定j2ee产品应遵循何种标
有的j2ee产品实现了在本产
陆（如IBM WebSphere Appl
WebSphere Application Se
WebSphere Application Se
点登陆是通过传递凭证（Cr
WEB客户端和应用程序客户
security Context），安全
全策略来判断用户是否有访
式，因此不能在不同厂商的
产品间互相共享安全上下文
LDAP server等）集成的方

指用户在特定的逻辑安全区域中
系统中的被授权的资源，只有超
系统共存的企业显得尤为有价值
越来越多。在传统的应用系统中
组织结构定义，安全角色定义，
用户在使用每一应用系统之前，
须记住每一个系统的用户名和密
概念随之产生，并不断的应用到
e产品应为应用系统提供单点登
准，因此不同的厂商的产品在单
品环境范围内的单点登陆，有的
ication 4.0 AE 实现了WebSphe
rver、WebSphere Application
rver与Lotus Domino server之
edential）来实现的.当用户进
端）根据用户的凭证（Credenti
上下文包含用于验证用户的安全
问系统资源的权限。遗憾的时j2
j2ee产品之间传递安全上下文。
，因此在不同j2ee产品间实现单
式。

，只需进行一次登陆即可在访问在
越了安全区域边缘时才要求再次登
。随着企业信息化建设程度的不断
，各系统各自维护自己的安全策略
用户身份验证，资源访问控制等。
都必须按照相应的系统身份进行系
码，给用户带来了不小的麻烦。针
企业的应用系统的集成当中。
陆的能力。但j2ee1.3规范并没有
点登陆上的实现和应用各不相同。
实现了特定系统环境之间的单点登
re Application Server与
Server与Lotus Domino server、
间的单点登陆能力）。在j2ee中单
行系统登陆时，客户端容器（包括
al）为用户建立一个安全上下文（
信息，系统用这个安全上下文和安
ee规范并没有规定安全上下文的格
到目前为止还很少有在不同的j2ee
点登陆只能通过第三方产品（如

　　● 惰性验证（Lazy Authentication）

　　身份验是有代价的。例如，一次验证
就非常有用了。惰性验证使当用户访问受
发起请求时就执行验证过程。

过程也许包括多次通过网络信息交换。因此惰性验证
保护的资源时才执行验证过程，而不是在用户第一次

　　J2ee的授权模型

　　● 代码授权（Code Authorization）

　　j2ee产品通过java 2
统的安全。详细描述请参阅

安全模型来限制特定J2SE的类和
《J2SE规范文档》。

方法的执行，以保护和确保操作系

　　● 调用者授权（Caller Authorization）

　　安全角色：安全角色是具有相同安全
Application Assembler）或应用程序的

属性的逻辑组。它由应用程序的装配者（
部署者（Application Deployer）分配的。

　　● 安全角色引用：安全角色引用是
安全角色的标识。应用程序提供者（Appl
色分配资源访问的权限。也在安全相关的

应用程序提供者（Application Provider）用来引用
ication Provider）可以用安全角色引用来为安全角
程序代码中引用安全角色。

　　● 用户和组：用户和
的人和群体。

组是在实际系统环境下的用户和

用户的集合。它们对应者现实当中

　　● 访问控制：访问控
对象包括EJB的远程方法、w
j2ee中访问控制在应用程序

制可以确保安全角色只能访问已
eb资源（html网页，jsp/servle
描述文件中与安全角色关联起来

授予它安全权限的授权对象。授权
t和多媒体或二进制文件）等。在
。

　　● 映射：通过映射应用程序的系统
系起来，从而是实际的用户拥有对企业资

管理员将实际系统环境中的用户和角色与安全角色联
源访问的适当授权。

　　● 被传播的调用者身份标识（Propa

gated Caller Identities）

　　在j2ee 1.3中可以选择
证。在这种方式下，整个ej
CallerPrincipal返回相同
jsp/servlet调用的，inter
principal name）应与inte
。要注意的是在调用链中传
要，因为在调用链的每个节

用传播调用者标识作为web组件
b组件的调用链中interface EJB
的主体名（principal name）。
face EJBContext的方法getCall
rface HttpServletRequest的方
递的是用户的标识，而不是凭证
点上用户可能使用不同的安全属

和ejb组件调用者的标识来进行验
Context的方法get
如果调用链中的第一个ejb是被
erPrincipal返回的主体名（
法getUserPrincipal的返回值相同
（credentials），这一点非常重
性。

　　Run As Identities

　　J2ee 1.3中提供了允许
j2ee1.3规范的产品会提供
Identities方式被选中，在
中第一个节点的调用者了，
为与被设置为Run As Ident

组件开发者和部署这来指定组件
将组件设置成Run As Identitie
运行中被设置为Run As Identit
而是在部署时被指定的调用者。
ities的组件的调用者相同。

以什么身份运行的方法。符合
s方式的方法。如果Run As
ies的组件的调用者不再是调用链
而调用链中随后节点的调用者也变

　　j2ee为我们提供了对于
用j2ee为我们提供的这些服
扩展性和可维护性。只有在
安全产品或自己开发安全服

验证和授权的安全服务，在开发
务。因为只有遵循j2ee标准，才
所选j2ee产品不能满足特定的安
务。

基于j2ee的应用时应该尽可能的使
能使你的应用具有良好的移植性、
全需求时，才应该考虑使用第三方