解析J2EE中的安全问题

核心提示：现在越来越多的企业应用构建在j2ee平台上，这得益于j2ee为企业应用的开发提供了良好的框架和服务的支持.j2ee为企业应用提供了多方面的服务(Security、Transaction、Naming等)，解析J2EE中的安全问题，本文将介绍j2ee提供的安全服务，首先介绍j2ee中的安全概念和j2ee的安全体系架构，给

　　现在越来越多的企业应用构建在j2ee平台上，这得益于j2ee为企业应用的开发提供了良好的框架和服务的支持.j2ee为企业应用提供了多方面的服务(Security、Transaction、Naming等)。本文将介绍j2ee提供的安全服务。首先介绍j2ee中的安全概念和j2ee的安全体系架构，然后结合具体的实例向读者展示如何在程序中应用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 产品必须为应用程序开发者提供两种形式的基于容器的安全性－说明性的安全性和可编程的安全性。
　　
　　● 说明性的安全性
　　
　　说明性的安全性通过安全结构描述的方式来代表应用程序的安全需求，安全结构一般包括安全角色，访问控制和验证要求等。在j2ee平台中部署描述符充当了说明的安全性的主要工具。部署描述符是组件开发者和应用程序部署者或应用程序组装者之间的交流工具。应用程序的开发者用它来表示应用中的安全需求，应用程序部署者或应用程序组装者将安全角色与部署环境中的用户和组映射起来。
　　
　　在程序运行时容器从部署描述符中提取出相应的安全策略，然后容器根据安全策略执行安全验证。说明的安全性不需要开发人员编写任何安全相关的代码，一切都是通过配置部署描述符来完成的。
　　
　　● 可编程的安全性
　　
　　可编程的安全性在说明性的安全性的基础上，使安全敏感的应用可以通过调用被容器提供的API来对安全作出决断。这在说明性的安全性不足以满足企业的安全模型的情况是非常有用的。J2ee在EJB EjbConext interface和servlet HttpServletRequest interface中各提供两个方法：
　　
　　isCallerInRole (EJBContext)
　　
　　getCallerPrincipal (EJBContext)
　　
　　isUserInRole (HttpServletRequest)
　　
　　getUserPrincipal (HttpServletRequest)
　　
　　这些方法答应组件根据调用者或远程用户的安全角色来作出商业判定。在文章的后面部分将有这些方法的具体介绍和例程，以便读者更好的理解可编程的安全性的用途。 J2ee的验证模型
　　
　　身份验证是用户或组件调用者向系统证实其身份的过程。用户通过某种方式向系统提交验证信息（通常是用户名和密码或者是用户的数字证书），系统用用户提供的验证信息和系统的安全策略来验证用户的身份。
　　
　　● 用户的验证
　　
　　用户的验证根据其客户端类型不同分为两种：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应用系统共存的企业显得尤为有价值。随着企业信息化建设程度的不断提高，企业中的应用系统也越来越多。在传统的应用系统中，各系统各自维护自己的安全策略，这些安全策略典型的包括组织结构定义，安全角色定义，用户身份验证，资源访问控制等。由于各系统互相独立，一个用户在使用每一应用系统之前，都必须按照相应的系统身份进行系统登陆。这对于用户来说必须记住每一个系统的用户名和密码，给用户带来了不小的麻烦。针对于这种情况，单点登陆的概念随之产生，并不断的应用到企业的应用