解析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平台中部署描述 和应用程序部署者或应用程序组 spring framework高危漏洞安全需求，应用程序部署者或应 | 序的安全需求，安全结构一般包括 符充当了说明的安全性的主要工具 装者之间的交流工具。应用程序的 用程序组装者将安全角与部署环 |
在程序运行时容器从部 全验证。说明的安全性不需 符来完成的。 | 署描述符中提取出相应的安全策 要开发人员编写任何安全相关的 | 略，然后容器根据安全策略执行安 代码，一切都是通过配置部署描述 |
● 可编程的安全性
可编程的安全性在说明 的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）的标 务器将使用客户端提供的数字证书来验证用户的身份 |
版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。
发表评论