http://www.ebuilds.net/news/kanwu/4/4-03.htm
前言
J2EE(Java 2 Platform Enterprise Edition)是美国Sun公司推出的多层企业应用开发模型。J2EE简化了基于工业标准的、组件化的企业应用开发，提供了一套完整的企业应用的开发框架和服务(Security、Transaction、Naming等)的支持。因此，越来越多的企业应用构建在J2EE平台上。在企业应用中，首要关心的是应用的安全性，本文首先介绍J2EE中的安全概念和J2EE的安全体系架构。最后展示在程序的开发中怎样应用J2EE提供的安全特性。
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 产品必须为应用程序开发者提供两种形式的基于容器的安全性：说明性的安全性和可编程的安全性。
I、说明性的安全性
说明性的安全性通过安全结构描述的方式来代表应用程序的安全需求，安全结构一般包括安全角色，访问控制和验证要求等。在J2EE平台中部署描述符充当了说明的安全性的主要工具。部署描述符是组件开发者和应用程序部署者或应用程序组装者之间的交流工具。应用程序的开发者用它来表示应用中的安全需求，应用程序部署者或应用程序组装者将安全角色与部署环境中的用户和组映射起来。
在程序运行时容器从部署描述符中提取出相应的安全策略，然后容器根据安全策略执行安全验证。说明的安全性不需要开发人员编写任何安全相关的代码，一切都是通过配置部署描述符来完成的。
II、可编程的安全性
可编程的安全性在说明性的安全性的基础上，使安全敏感的应用可以通过调用容器提供的API来对安全作出决断。这在说明性的安全性不足以满足企业的安全模型的情况是非常有用的。J2EE在EJB EjbConext interface和servlet HttpServletRequest interface中各提供两个方法：
isCallerInRole (EJBContext)
getCallerPrincipal (EJBContext)
isUserInRole (HttpServletRequest)
GetUserPrincipal (HttpServletRequest)
这些方法允许组件根据调用者或远程用户的安全角色来作出商业判断。
2、J2EE的验证模型
身份验证是用户或组件调用者向系统证明其身份的过程。用户通过某种方式向系统提交验证信息（通常是用户名和密码或者是用户的数字证书），系统以用户提供的验证信息和系统的安全策略来验证用户的身份。
 |
| 图一 初始验证过程 |
 |
| 图二 验证URL |
 |
| 图三 验证EJB方法调用 |
I、Web 客户端的验证
Web客户端通常通过http协议来请求web服务器端的资源，这些web资源通常包括html网页、jsp（java server page）文件、java servlet和其他一些二进制或多媒体文件。在企业环境中，企业的某些资源往往要求只允许某些人访问，有些资源甚至是机密的或安全敏感的。因此对企业中各种web资源进行访问控制是十分必要的。为了满足企业中的不同安全级别和客户化的需求，J2EE提供了三种基于web客户端的验证方式：
●HTTP基本验证（HTTP Basic Authentication）
●基于表单的验证（Form-Based Authentication）
●基于客户端证书的验证（Client-Certificate Authentication）
II、应用程序客户端的验证
Java客户端程序是执行在用户本地java虚拟机上的java程序，它拥有main方法，通常用户可通过java.exe或javaw.exe直接启动执行。J2EE应用程序客户端与java客户端程序相似，也拥有main方法，但他们在运行时存在一定的差别。J2EE应用程序客户端和其他J2EE组件一样运行在自己的容器中。用户通过容器来执行J2EE应用程序客户端。这样J2EE应用程序客户端容器就有机会在J2EE应用程序客户端被执行之前完成用户身份的验证。J2EE提供了一种可自定义的方式来获取用户的验证信息。可以选择使用容器提供的缺省的方式来获取J2EE应用客户端程序的用户的验证信息，也可以选择自定义的方式来获取用户的验证信息。
3、J2EE的授权模型
I、代码授权（Code Authorization）
J2EE产品通过java 2 安全模型来限制特定J2SE的类和方法的执行，以保护和确保操作系统的安全。
II、调用者授权（Caller Authorization）
安全角色：安全角色是具有相同安全属性的逻辑组。它由应用程序的装配者（Application Assembler）或应用程序的部署者（Application Deployer）分配的。
III、安全角色引用
安全角色引用是应用程序提供者（Application Provider）用来引用安全角色的标识。应用程序提供者（Application Provider）可以用安全角色引用来为安全角色分配资源访问的权限，也可以在安全相关的程序代码中引用安全角色。
IV、用户和组
用户和组是在实际系统环境下的用户和用户的集合。它们对应着现实当中的人和群体。
V、访问控制
访问控制可以确保安全角色只能访问已授予它安全权限的授权对象。授权对象包括EJB的远程方法、web资源（html网页，jsp/servlet和多媒体或二进制文件）等。在J2EE中访问控制在应用程序描述文件中与安全角色关联起来。
VI、映射
通过映射应用程序的系统管理员将实际系统环境中的用户和角色与安全角色联系起来，从而是实际的用户拥有对企业资源访问的适当授权。
VII、被传播的调用者身份标识
在J2EE 1.3中可以选择用传播调用者标识作为web组件和ejb组件调用者的标识来进行验证。在这种方式下，整个ejb组件的调用链中interface EJBContext的方法getCallerPrincipal返回相同的主体名（principal name）。如果调用链中的第一个ejb是被jsp/servlet调用的，interface EJBContext的方法getCallerPrincipal返回的主体名（principal name）应与interface HttpServletRequest的方法getUserPrincipal的返回值相同。要注意的是在调用链中传递的是用户的标识，而不是凭证（credentials），这一点非常重要，因为在调用链的每个节点上用户可能使用不同的安全属性。
VIII、Run As Identities
J2EE 1.3中提供了允许组件开发者和部署者来指定组件以什么身份运行的方法。符合J2EE1.3规范的产品会提供将组件设置成Run As Identities方式的方法。如果Run As Identities方式被选中，在运行中被设置为Run As Identities的组件的调用者不再是调用链中第一个节点的调用者了，而是在部署时被指定的调用者。而调用链中随后节点的调用者也变为与被设置为Run As Identities的组件的调用者相同。