J2EE 中的安全

本文所介绍的内容是基于j2ee1.3版本的。

j2ee中的安全概念:

主体（Principal）：主体（Principal）是被在企业安全服务验证了的实体。主体（Principal）用主体名作为它的标识，通过与主体相关的验证数据进行验证。通常情况下主体名就是用户的登陆名，验证数据就是登陆的密码。J2EE规范中并没有限定J2EE 产品提供商使用怎样的认证方法，因此主体名和验证数据的内容和格式依不同的认证协议而不同。

安全策略域（Security Policy Domain）：也称安全域（security domain）或 realm，它是一个逻辑范围或区域，在这一范围或区域中安全服务的管理员定义和实施通用的安全策略。它是从安全策略的角度划分的区域。比如可以将企业应用系统划分为企业员工、供应商、合作伙伴等不同的安全域，对这些安全区域采用不同的安全策略。

安全技术域（Security Technology Domain）：它是从安全技术的角度划分的区域，在一个安全技术域中使用同样的安全机制来执行安全策略。一个安全技术域可以包括多个安全策略域。

安全属性（Security Attributes）：每个主体（Principal）都有一系列与之相关的安全属性。安全属性可用来访问被保护的资源，检查用户的身份和完成其他一些安全相关的用途。J2EE产品提供商或具体的验证服务的实现来决定怎样将安全属性与一个主体联系起来。J2EE规范并没有限定什么样的安全属性将与主体相联系。

凭证（Credential）：凭证包含或引用为J2EE 系统验证一个主体的验证信息（安全属性）。如果成功的通过了验证，主体将获得一个包括安全属性的凭证。如果被允许的话，一个主体也可能获取另一个主体的凭证。在这种情况下两个主体在同一安全域中具有相同的安全属性。


j2ee的安全体系结构:

1． 基于容器的安全

在j2ee的环境中，组件的安全是由他们各自的容器来负责的，组件的开发人员几乎可以不用或者很少在组件中添加有关安全的代码。这种安全逻辑和业务逻辑相对独立的架构，使得企业级应用系统有更好的灵活性和扩展性。J2ee规范要求j2ee 产品必须为应用程序开发者提供两种形式的基于容器的安全性－说明性的安全性和可编程的安全性。

a. 说明性的安全性

说明性的安全性通过安全结构描述的方式来代表应用程序的安全需求，安全结构一般包括安全角色，访问控制和验证要求等。在j2ee平台中部署描述符充当了说明的安全性的主要工具。部署描述符是组件开发者和应用程序部署者或应用程序组装者之间的交流工具。应用程序的开发者用它来表示应用中的安全需求，应用程序部署者或应用程序组装者将安全角色与部署环境中的用户和组映射起来。

在程序运行时容器从部署描述符中提取出相应的安全策略，然后容器根据安全策略执行安全验证。说明的安全性不需要开发人员编写任何安全相关的代码，一切都是通过配置部署描述符来完成的。

b. 可编程的安全性

可编程的安全性在说明性的安全性的基础上，使安全敏感的应用可以通过调用被容器提供的API来对安全作出决断。这在说明性的安全性不足以满足企业的安全模型的情况是非常有用的。J2ee在EJB EjbConext interface和servlet HttpServletRequest interface中各提供两个方法：
isCallerInRole (EJBContext)
getCallerPrincipal (EJBContext)
isUserInRole (HttpServletRequest)
getUserPrincipal (HttpServletRequest)
这些方法允许组件根据调用者或远程用户的安全角色来作出商业判断。在文章的后面部分将有这些方法的详细介绍和例程，以便读者更好的理解可编程的安全性的用途。

2．J2ee的验证模型

身份验证是用户或组件调用者向系统证明其身份的过程。用户通过某种方式向系统提交验证信息（通常是用户名和密码或者是用户的数字证书），系统用用户提供的验证信息和系统的安全策略来验证用户的身份。

图一 初始验证过程

 

图二 验证URL
图三 验证EJB方法调用

用户的验证

用户的验证根据其客户端类型不同分为两种：Web 客户端的验证和Application客户端的验证

a. Web 客户端的验证

Web客户端通常通过http协议来请求web服务器端的资源，这些web资源通常包括html网页、jsp（java server page）文件、java servlet和其他一些二进制或多媒体文件。在企业环境中，企业的某些资源往往要求只允许某些人访问，有些资源甚至是机密的或安全敏感的。因此对企业中各种web资源进行访问控制是十分必要的。为了满足企业中的不同安全级别和客户化的需求，j2ee提供了三种基于web客户端的验证方式：

HTTP基本验证（HTTP Basic Authentication）
HTTP基本验证 是HTTP协议所支持的验证机制。这种验证机制使用用户的用户名和密码作为验证信息。Web客户端从用户获取用户名和密码，然后传递他们给web服务器，web服务器在指定的区域（realm）中验证用户。但需要注意的是，这种验证方法是不够安全的。因为这种验证方法并不对用户密码进行加密，而只是对密码进行基本的base64的编码。而且目标web服务器对用户来说也是非验证过的。不能保证用户访问到的web服务器就是用户希望访问的。可以采用一些安全措施来克服这个弱点。例如在传输层上应用SSL或者在网络层上使用IPSEC或VPN技术。

基于表单的验证（Form-Based Authentication）
基于表单的验证 使系统开发者可以自定义用户的登陆页面和报错页面。这种验证方法与基本HTTP的验证方法的唯一区别就在于它可以根据用户的要求制定登陆和出错页面。基于表单的验证方法同样具有与基本HTTP验证类似的不安全的弱点。用户在表单中填写用户名和密码，而后密码以明文形式在网路中传递，如果在网路的某一节点将此验证请求截获，在经过反编码很容易就可以获取用户的密码。因此在使用基本HTTP的验证方式和基于表单的验证方法时，一定确定这两种方式的弱点对你的应用是可接受的。

基于客户端证书的验证（Client-Certificate Authentication）
基于客户端证书的验证方式要比上面两种方式更安全。它通过HTTPS（HTTP over SSL）来保证验证的安全性。安全套接层（Secure Sockets Layer）为验证过程提供了数据加密，服务器端认证，信息真实性等方面的安全保证。在此验证方式中，客户端必须提供一个公钥证书，你可以把这个公钥证书看作是你的数字护照。公钥证书也称数字证书，它是被称作证书授权机构（CA）－一个被信任的组织颁发的。这个数字证书必须符合X509公钥体系结构（PKI）的标准。如果你指定了这种验证方式，Web服务器将使用客户端提供的数字证书来验证用户的身份。

b. 应用程序客户端的验证（Application Client User Authentication）
java客户端程序是执行在用户本地java虚拟机上的java程序，它拥有main方法，通常由用户可通过java.exe或javaw.exe直接启动执行。J2ee应用程序客户端与java客户端程序相似，也拥有main方法，但他们在运行时存在一定的差别。J2ee应用程序客户端和其他j2ee组件一样运行在自己的容器中。用户通过容器来执行J2ee应用程序客户端。这样J2ee应用程序客户端容器就有机会在J2ee应用程序客户端被执行之前完成用户身份的验证。J2ee提供了一种可自定义的方式来获取用户的验证信息。可以选择使用容器提供的缺省的方式来获取j2ee应用客户端程序的用户的验证信息，也可以选择自定义的方式来获取用户的验证信息。当选择自定义方式时，应用程序开发者必须提供一个实现了javax.security.auth.callback.CallbackHandler interfce的类,并且在j2ee部署描述文件application-client.xml中的元素callback-handler中加入这个类的类名。这样，当系统需要验证用户身份时，客户端程序的容器将部署描述文件中的CallbackHandler实现类的类名传递给系统的登陆模块（验证模块），登陆模块再实例化这个实现类。这个类的实例负责收集用户验证信息，并将收集到的用户验证信息传递给登陆模块，登陆模块用这些验证信息来验证用户。这个实现类可以是具有用户界面的，或是通过要求用户输入来收集用户验证信息，也可以是通过命令行来获取用户验证信息，还可能是通过读取本地或在线的用户证书库来获取用户的电子证书。选取哪种方式取决于验证信息的存储方式。

有些j2ee产品厂商把容器的验证服务和本地系统的验证服务或其他应用系统产品的验证服务集成起来，从而在一定的应用系统的范围内实现单点登陆的能力。

单点登陆 （Single Sign-On）
单点登从用户的视角是指用户在特定的逻辑安全区域中，只需进行一次登陆即可在访问在此逻辑安全区域中不同应用系统中的被授权的资源，只有超越了安全区域边缘时才要求再次登陆。这种能力对多种IT应用系统共存的企业显得尤为有价值。随着企业信息化建设程度的不断提高，企业中的应用系统也越来越多。在传统的应用系统中，各系统各自维护自己的安全策略，这些安全策略典型的包括组织结构定义，安全角色定义，用户身份验证，资源访问控制等。由于各系统互相独立，一个用户在使用每一应用系统之前，都必须按照相应的系统身份进行系统登陆。这对于用户来说必须记住每一个系统的用户名和密码，给用户带来了不小的麻烦。针对于这种情况，单点登陆的概念随之产生，并不断的应用到企业的应用系统的集成当中。J2ee1.3也在规范中建议j2ee产品应为应用系统提供单点登陆的能力。但j2ee1.3规范并没有规定j2ee产品应遵循何种标准，因此不同的厂商的产品在单点登陆上的实现和应用各不相同。有的j2ee产品实现了在本产品环境范围内的单点登陆，有的实现了特定系统环境之间的单点登陆（如IBM WebSphere Application 4.0 AE 实现了WebSphere Application Server与WebSphere Application Server、WebSphere Application Server与Lotus Domino server、WebSphere Application Server与Lotus Domino server之间的单点登陆能力）。在j2ee中单点登陆是通过传递凭证（Credential）来实现的.当用户进行系统登陆时，客户端容器（包括WEB客户端和应用程序客户端）根据用户的凭证（Credential）为用户建立一个安全上下文（security Context），安全上下文包含用于验证用户的安全信息，系统用这个安全上下文和安全策略来判断用户是否有访问系统资源的权限。遗憾的时j2ee规范并没有规定安全上下文的格式，因此不能在不同厂商的j2ee产品之间传递安全上下文。到目前为止还很少有在不同的j2ee产品间互相共享安全上下文，因此在不同j2ee产品间实现单点登陆只能通过第三方产品（如LDAP server等）集成的方式。

惰性验证（Lazy Authentication）
身份验是有代价的。例如，一次验证过程也许包括多次通过网络信息交换。因此惰性验证就非常有用了。惰性验证使当用户访问受保护的资源时才执行验证过程，而不是在用户第一次发起请求时就执行验证过程。

3. J2ee的授权模型


代码授权（Code Authorization）
j2ee产品通过java 2 安全模型来限制特定J2SE的类和方法的执行，以保护和确保操作系统的安全。详细描述请参阅《J2SE规范文档》。

调用者授权（Caller Authorization）
安全角色：安全角色是具有相同安全属性的逻辑组。它由应用程序的装配者（Application Assembler）或应用程序的部署者（Application Deployer）分配的。

安全角色引用：安全角色引用是应用程序提供者（Application Provider）用来引用安全角色的标识。应用程序提供者（Application Provider）可以用安全角色引用来为安全角色分配资源访问的权限。也在安全相关的程序代码中引用安全角色。

用户和组：用户和组是在实际系统环境下的用户和用户的集合。它们对应者现实当中的人和群体。

访问控制：访问控制可以确保安全角色只能访问已授予它安全权限的授权对象。授权对象包括EJB的远程方法、web资源（html网页，jsp/servlet和多媒体或二进制文件）等。在j2ee中访问控制在应用程序描述文件中与安全角色关联起来。

映射：通过映射应用程序的系统管理员将实际系统环境中的用户和角色与安全角色联系起来，从而是实际的用户拥有对企业资源访问的适当授权。

被传播的调用者身份标识（Propagated Caller Identities）
在j2ee 1.3中可以选择用传播调用者标识作为web组件和ejb组件调用者的标识来进行验证。在这种方式下，整个ejb组件的调用链中interface EJBContext的方法getCallerPrincipal返回相同的主体名（principal name）。如果调用链中的第一个ejb是被jsp/servlet调用的，interface EJBContext的方法getCallerPrincipal返回的主体名（principal name）应与interface HttpServletRequest的方法getUserPrincipal的返回值相同。要注意的是在调用链中传递的是用户的标识，而不是凭证（credentials），这一点非常重要，因为在调用链的每个节点上用户可能使用不同的安全属性。

Run As Identities
J2ee 1.3中提供了允许组件开发者和部署这来指定组件以什么身份运行的方法。符合j2ee1.3规范的产品会提供将组件设置成Run As Identities方式的方法。如果Run As Identities方式被选中，在运行中被设置为Run As Identities的组件的调用者不再是调用链中第一个节点的调用者了，而是在部署时被指定的调用者。而调用链中随后节点的调用者也变为与被设置为Run As Identities的组件的调用者相同。