javaee-5_0-fr-spec (六)

EE.3 安全

本章描述了JavaEE产品必须满足的J2EE平台对安全的要求.

额外地, 每个JavaEE产品厂商必须在他们的实现中决定安全等级和安全保证.

 

EE.3.1 介绍

差不多每家企业都有安全要求, 并且会有相应的机制和结构来满足要求. 可以被很多用户访问的或者能够被开放式未被保护网络访问的敏感资源都应该被保护.

      尽管保证质量和实现细节会不同, 他们共同具有以下特征:

      ● 验证: 互相关联的实体(例如, 客户端和服务器)可以相互验证获得特别通行许可, 从而获得访问授权.

      ● 资源访问控制: 对资源进行控制从而限制用户或者程序访问, 来达到保密性,完整性和可用性的系统要求.

      ● 数据完整: 需要验证信息是否被第三方修改过.(比如某些实体已经不是原来的信息). 例如, 接受方通过网络发出的信息在被修改过, 则应该能被检测及丢弃.

      ● 欺骗和数据隐私:确保信息只能被已授权访问它的用户访问.

      ● 不可否认性: 用户不能否认他们做过的事情.

      ● 审查: 这个特征意味着可以采集安全事件相关的不可窜改记录, 从而可以使用这些记录来论证安全策略和机制的效果.

     

      本章节指出JavaEE平台上怎样处理安全需求, 并且标识出哪些要由JavaEE产品厂商来处理. 最后, 本规范未来的需要讨论的东西将会在Section EE.3.7"发展"中被提到.

 

EE.3.2 一个简单例子

 

 通过一个简单的例子可以更好的理解JavaEE环境的安全行为. 这个例子包括: Web客户端, Jsp用户接口, enterprise bean业务逻辑.(这个例子并不包含特殊情况)

 

      在这个例子中, Web客户端收集验证数据并且使用这些数据通过Web服务器来做为它的验证代理, 从而建立一个验证过的会话.

第一步: 初始化请求

      Web客户端请求主应用的URL, 如图片EE.3-1所示.

      由于客户端并没有通过应用环境的身份验证, 所以服务器有责任来为应用提供Web这部分来检测这一块, 并且调用合适的验证机制来保护资源.

 

第二步: 初始化验证

      Web服务器返回一个表单, Web客户端使用它来收到验证信息(例如: 用户名和密码). Web客户端继续将验证数据送到Web服务器, Web服务器来验证它, 如Figure EE.3-2所示.

     

 验证机制可能只影响到服务器, 也可以影响下层的安全服务.  如果通过了验证, Web服务器就给用户发送一个信任标识.

 

第三步: URL授权

当用户访问受限资源的时候, 该信任标识就被用来判断用户是否被授权了.  Web服务器获取安全策略(从部署描述符中获取)关联的Web资源来决定当前安全角色是否被允许访问该资源. Web容器接下来会把当前用户的信任标识与每个角色相比对, 判断它能否把用户映射到角色. 如图EE.3-3所示.

 当Web服务器能将用户映射到角色, 那么Web服务器就将以"已授权"为输出结果.

 当Web服务器不能将用户映射到任何角色, 那么Web服务器就将以"未授权"为输出结果.

 

第四步: 全部的初始请求

如果用户已授权, Web服务器将返回原始请求的结果, 如下图EE.3-4所示.

 

 

在我们的例子的中, 返回的是一个JSP页面的url, 从而可以让用户提交那些要被应用的业务逻辑组件所处理的数据.

 

第五步: 调用Enterprise Bean业务方法.

JSP页面使用用户凭证与enterprise bean建立安全连接, 从而呼叫enterprise bean的远程方法(如图表EE.3-5所示).这个关联是通过两边的安全上下文建立的, 一个是在web服务器端, 另一个是在EJB容器里.