java如何保障传输消息安全_《深入理解JAVA EE应用服务器》 之安全章节系列之一 JavaEE安全概览...

The Java EE 6 Tutorial

本章讨论下在web层和企业层应用的安全。每个企业都有一些被特定用户访问的敏感资源，或者处于开放的网络环境下，需要被保护的资源。

本章介绍基本的安全概念以及安全机制，更多的相关信息可以在Java EE 6规范中找到：http://www.jcp.org/en/jsr/detail?id=316。

安全分为以下两个章节：

如何给web组件添加安全，例如servlet

如何为JavaEE组件添加安全，例如企业Bean和application clients.

JavaEE安全概览

http://docs.oracle.com/javaee/6/tutorial/doc/bnbwk.html

企业层和web层的应用是由部署在不同容器的组件组成的。应用各个组件的安全是由其容器提供的。一个容器提供两种安全：声明或者编码。

声明式安全使用部署描述符或者注解。部署描述符描述了一个应用的安全架构，包括安全用户，访问控制，授权需求等。参看Java Servlet 3.0 specification (JSR 315) web.xml；EJB 3.1 specification (JSR 318) META-INF/ejb-jar.xml

注解也叫元注释，用于在类中定义安全信息。当应用部署后，这些信息可以被部署描述文件使用或者重写。注解省去了编写xml描述符中的生命信息，只需要简单的在代码中添加注解，所需的信息就生成了。

编程式安全被嵌入在应用程序中，用于处理相关的安全逻辑。编程式安全在声明式安全不能够完整的表达应用程序的安全模型时会很有用处。

一个简单的应用程序安全示例

初始化请求

客户端请求应用的url，因为客户端还没有被授权，被服务器即web server检测到，并做出合适的授权机制响应。

Figure 39-1 Initial Request

授权初始化

Web服务器向客户端返回一个用于收集授权信息的表单，例如包含了用于输入用户名和密码。客户端将授权信息返回给web服务器。校验机制可能是一个本地的机制，也可能利用现有的安全服务。以校验为基础，web服务器会为用户设置一个证书。

Figure 39-2 Initial Authentication

URL授权

证书用于进一步确认是否用户有权限访问受保护的资源。Web服务器会咨询安全策略，该安全策略与决定安全角色是否允许访问的web资源相关联。安全策略源于注解或者部署描述文件。然后Web容器监测用户的证书是否能使用户与相应的角色相对应。

Figure 39-3 URL Authorization

返回最初的请求

如果用户已被授权，web服务器返回最初的url请求结果。

在本用例中，一个url响应网页被返回了，用户能够继续发送表单数据进行业务逻辑的处理。

调用EJB业务方法

Web网页对EJB进行了远程方法调用，使用了用户的证书在网页与EJB直接简历了一个安全连接。该连接被实现为两种相关联的安全上下文：一个在web容器一个在EJB容器。

Figure 39-5 Invoking an Enterprise Bean Business Method

EJB容器负责EJB方法的访问控制。容器咨询与EJB相关的安全策略，用于判断安全角色是否允许访问相关方法。对于每个角色，EJB容器使用与本次调用相关的安全上下文决定是否调用者与角色相对应。

如果结果是未授权，则抛出异常并传递给调用页面。如果调用以被授权，容器将跳转至EJB方法，EJB的处理结果被返回至web页面。

安全机制特性

安全机制的实现应当具备以下功能：

阻止未被授权的请求访问应用功能，业务方法，或者个人数据(授权)

使系统用户对他们的操作能够负责(不可否认)

使系统免受服务中断或者其他影响服务质量的情况。

理想情况下，安全机制也应该：

易管理

对系统用户透明

同时适用于应用和企业级应用

应用安全特征

Java EE应用可能同时包含了受保护和不受保护的应用。通常会确保只有授权用户能够访问受保护资源。授权提供了对受保护资源的访问控制。授权(Authorization)基于鉴别(identification)和认证(authentication)。鉴别是指对实体的识别过程，认证则指检查用户或其他实体的身份信息。授权和认证对于不受保护的资源是不必要的。

应用安全特征，帮助最大限度的降低企业应用面临的安全威胁：

认证(Authentication)：通信实体，例如客户端和服务器，互相证明他们就是被授权访问的特定身份的方法。

授权或者访问控制(Authorization, oraccess control)：与资源的交互被限制于用户或程序集合，用于实现完整性，机密性，可用性。这保证了用户有操作或者访问数据的权限。

数据完整性(Data integrity)：用于证明信息没有被第三方所篡改。例如，在开放的网络上的数据接收方必须能监测到并抛弃被篡改的信息。这保证了只有授权用户能够修改数据。

机密性(Confidentiality, ordata privacy)：信息只对授权用户可见。这意味着只有授权用户能够浏览敏感数据。

不可否认性(Non-repudiation)：用户无法对自己进行的操作进行否认。这保证了事务能够被证明发生过。

服务质量(Quality of Service)：使用各种技术在网络状态不好的情况下提供更好的服务。

审计(Auditing)：捕获安全相关的抗干扰事件的记录，对安全策略和机制的效率进行评估。因此系统需维护一个事务和安全信息的记录。

安全机制

http://docs.oracle.com/javaee/6/tutorial/doc/bnbwy.html

在确定为应用提供哪种层次和类型的安全保障时，应当考虑应用的特性。本章讨论了为JavaEE应用提供安全保障的常见机制特性。每种机制都可以根据具体需求单独或者结合使用从而提供安全保护。

JavaSE安全机制

Java SE提供多样的安全特性和机制支持：

Java Authentication and Authorization Service (JAAS) ：JAAS是一组提供授权和访问控制的API。JAAS为可编程的用户验证和授权提供了可插拔和可扩展的框架。JAAS是Java SE的核心API，也是Java EE安全机制的基础技术。

Java Generic Security Services (Java GSS-API) ：Java GSS-API是一种基于令牌(token-based)的API，用于通信应用之间的安全信息交换。GSS-API为程序员提供了统一的安全服务访问，这些安全服务是在各种基础安全机制之上的，如Kerberos。

Java Cryptography Extension (JCE)：JCE提供了一组 用于加密、密钥生成和协商以及 Message Authentication Code(MAC)算法的框架和实现。它提供对对称、不对称、块和流密码的加密支持，块加密操作一组byte数组，流加密每次操作一个byte。它还支持安全流和密封的对象。

Java Secure Sockets Extension (JSSE)：JSSE提供SSL的框架和实现以及传输层安全(TLS)协议并包括了数据加密，服务器认证，消息整合，可选的客户端认证。

Simple Authentication and Security Layer (SASL)：SASL是一个网络标准。它定义了认证协议以及客户端和服务端安全层的建立。SASL定义了认证数据是怎样交换的而且不是他自己指定了数据内容。SASL是指定了认证数据的内容和语义的特定的认证机制能够适用的框架。

JavaSE也提供一组工具，用于管理密钥库，证书和策略文件；生成并校验jar签名，获取、列出并管理Kerberos tickets。

JavaEE安全机制

JavaEE安全服务是由容器提供的，可以使用声明式或者编程式技术实现。JAVA EE安全服务提供强健的且易于配置的安全机制，用于认证用户和授权对各层应用功能和数据的访问。Java EE安全服务于操作系统的安全机制不同。

应用层安全

在Java EE中，容器提供应用层的安全保障、安全服务来满足特定应用类型的相关需求。在应用层，应用防火墙通过保护通信流和相关资源不受攻击从而保护应用。Java EE安全易实现和配置，且能提供对应用功能和数据的细粒度的访问控制。正如应用层安全固有的特点，安全属性不能够转移给其他环境下的应用。在传统的企业应用上下文中，这可能不是一个问题，但是在web service应用中，数据经过了多个中间人，这时候就需要使用Java EE安全机制与传输层安全和消息层安全共同组成一个完整的安全解决方案。

使用应用层安全的优点：

1. 适用于应用需求

2. 通过配置，实现细粒度的安全

缺点：

1. 应用依赖于不能够在应用之间传输的安全属性

2. 对多种协议的支持使安全比较脆弱。

3. 数据也比较易受攻击

传输层安全

传输层安全是由用户和提供者之间传输数据的传输机制提供的。因此，传输层安全依赖于使用SSL(Secure Socjets Layer)的HTTPS。传输层安全是点对点的安全机制，可以用于认证，消息整合和机密性。当使用SSL的session时，服务端和客户端能够相互认证并且协商一个加密算法和加密过的秘钥，而这些都是在应用发送或接收第一个byte数据之前的。数据在离开客户端到达目的地之间都是安全的，即使通过了中间人也没有关系。问题是当数据一旦到达目的地则不失去了传输层的安全保护，一个解决办法是在信息发送之前便将其加密。

传输层安全有以下时序：

1. 客户端与服务器简历合适的算法。

2. 使用公钥加密和基于证书的认证交换秘钥。

3. 在信息交换过程中进行对称加密。

SSL通信中需要用到 数字证书。多数的web服务器如果没有安装数字证书的话是不会提供https服务的。

传输层安全优点：

1. 相对简单、易理解，是通用的标准技术

2. 适用于消息体机器附属。

传输层安全缺点：

1. 与传输层协议紧耦合

2. 意味着安全的全或无( all-or-nothing)，安全机制不知道消息内容，所以不能像消息层安全那样选择性的对一部分消息应用安全机制。

3. 保护是临时的，只在传输过程中消息受保护，当客户端接受到消息后保护就失效了。

4. 并非端对端的解决方案，只是简单的点对点。

消息层安全

在消息层安全，安全信息包含于SOAP消息或SOAP消息的附属，使安全信息能够与消息或其附属一起发送。例如，部分消息可能被发送者标记且加密了。当发送者发送消息时，消息在到达目标接收者前可能会经过中间节点。在该场景下，被加密的部分对于中间节点来说仍然是不透明的，只能被目标接收者解密。因此，消息层安全有时也被称为点对点安全。

消息层安全优点：

1. 消息即使在到达目的地后仍然是安全的。

2. 安全能够被选择性的应用于消息或者其附属的不同部分

3. 消息安全适用有中间节点的情况

4. 不依赖于应用环境或者传输协议。

消息层安全的缺点就是相对比较复杂，且增加了负载。

GlassFish使用Metro支持消息层安全，Metro是一个使用WSS(Web Service Security)的web服务栈。消息层安全并非JavaEE平台的一部分，因此不讨论WSS对消息的安全加密。Metro详情 http://metro.java.net/guide/ .