计算机世界网-周报全文－从Java EE安全到Acegi

从Java EE安全到Acegi
■ 译自《JavaWorld》
Java EE安全和Acegi都提供了简化应用程序安全编程的诸多服务。Java EE中声明性和基于注释的编程方法让开发人员只要关注Java类中的业务问题。对于基于Spring开发的应用程序，Acegi则备受青睐，原因是它具有Java EE安全通常没有的增强特性。 Java EE是一种行业标准的编程平台，它把安全和事务等横切关注点（cross-cutting concerns）转化为标准服务，从而让开发人员摆脱了烦琐的基础架构编码工作。Java EE中的安全服务让开发人员轻而易举就能为应用程序建立强大、完备的保护机制。除了Java EE外，Spring这个流行的开源框架建立在Java EE标准之上，它解决了Java EE规范早期版本（1.0-1.4）所缺失或者有问题的部分。Spring具有的特性和价值，加上Spring容器可驻留在没有重型应用程序容器的Web服务器上，都使得Spring在应用框架市场继续占有主导地位。为Spring设计的Acegi提供了灵活、强大和全面的安全，这是Java EE标准所无法企及的。 企业安全 企业安全的目的是验证用户身份，授权合法用户访问不同的应用程序功能及相关数据。在许多公司，用户资料和安全信息保存在采用轻型目录访问协议（LDAP）形式的单一存储库中，或保存在关系数据库中，以便单次登录（SSO）。Java EE 5规范中的安全机制把具体的实现交给服务器开发商去完成，从而解决了常见、抽象的应用程序安全问题。使用标准Java EE安全服务的安全解决方案被称为容器管理的安全（CMS），可以在不同的Java EE平台之间进行移植。服务器开发商通常会提供专有的安全扩展件，解决该规范没有涉及的问题。 独立于标准Java EE安全的Acegi是一种开源安全系统，为使用Spring的应用程序提供了一系列丰富的安全服务。Acegi安全被描述成在Web归档（WAR）级、而不是Java EE采用的API级是可以移植的，这是因为Acegi运行环境作为应用程序的一部分部署在WAR文件里面。 Acegi和新的Java EE 5安全都得益于Java 5注释、面向方面的编程（AOP）以及依赖注入等技术，这些技术使得安全编程减少了干扰性、减少了代码数量、更加基于配置，实际上促进了普通Java对象（POJO）风格的编程。只需要少量的编程工作，就可以在这些标准化的安全服务上迅速、轻松开发所需要的安全解决方案。 Java EE中的验证 用户与安全网站进行交互时发生的第一件事就是验证。Java EE规范声明了四种不同的验证登录方法: 表单验证、基本验证、摘要验证和客户端证书（X509）验证。基本验证和表单验证是最常用的两种方法，而客户端证书验证更多地用于B2B通信，为了能够实现互动的HTTPS通信，就要求客户端和服务器交换可信的X509证书。 基于表单的登录可以控制HTTP浏览器呈现给用户的Web登录屏幕的外观感觉。登录HTML表单有一个预定义的动作: j_securitycheck，以及输入字段: j_username和j_password。 何不兼而用之 让Acegi与Java EE安全相互协作，这好比是锦上添花。Acegi的容器适配器通过容器特定的配置，集成了Acegi和Java EE安全。它能够使用Acegi安全和服务器小程序API中定义的安全方法，譬如getUserPrincipal()和isUserInRole()。Acegi目前支持Jetty、Catalina（Tomcat）、JBoss和Resin。很容易为其他Web服务器开发自定义容器适配器。 基本验证是HTTP协议里面定义的一种简单的登录机制: 只要收到HTTP状态代码401，就会显示一个登录弹出窗口。浏览器会利用username:password采用base64编码的值，构建一个验证令牌，然后放到请求消息的HTTP报头里面。 基于摘要的登录基本上是取代基本验证的方法，因为密码以一种摘要形式来传输，而摘要由SHA2或者MD5等单向散列函数计算出来，这种函数要比基本验证中采用base64编码的密码值来得安全。 验证的具体实现由服务器开发商来完成，这借助通常名为验证提供者（authentication provider）的自定义编程模块。验证提供者与后端数据存储区进行联系后，证明用户（或系统进程）的身份。几乎所有开发商都提供LDAP和Java数据库连接性（JDBC）验证提供者，验证保存在LDAP或者关系数据库中的用户资料。有些还支持Windows NT验证和多种SSO验证，譬如安全声明标记语言（SAML）、SiteMinder和CAS，作为开发商专有的安全扩展件。这些验证提供者可以与四种标准的登录方法协同工作，也可以把登录过程委托给某些集中式登录网站。在Java EE中，配置那些开发商专有的验证提供者超出了应用程序编程的范畴。因而，相关设置保存在应用程序的WAR或者EAR文件外面的自定义配置文件中。 不像Java EE，Spring和Acegi都具体实现了各自的API。Spring事实上促进了Web应用程序在WAR级的可移植性，那样WAR文件部署后立即就可以运行，不需要任何外部配置。换句话说，所有配置都在应用程序的WAR文件里面定义。 Acegi中的验证 Acegi为使用Spring的应用程序提供了灵活、全面的验证服务，这些服务通过服务器小程序过滤器来实现。除了表单、基本、摘要和客户端证书等常见的登录方法外，Acegi还支持匿名、remember-me和重定向等方法，实现某些集中式登录网站上进行的SSO验证。 Web应用程序通常有受保护及未受保护的URL，而匿名用户未经验证就可以访问未受保护的资源。不过在Acegi中，这种情况有所不同。Acegi中的匿名验证可以把匿名用户与特定的用户身份及角色关联起来，那样针对受保护及未受保护的资源，可以采用统一的方法为访问控制编写代码。 Acegi中的remember-me验证使网站在Web会话期间能够记住用户的身份。持续时间很长的cookie连同摘要身份的值和密码发送给浏览器，那样在将来的会话期间就能发现该cookie，从而可实现自动登录，这是许多商业网站所需要的一项特性。 单次登录往往是适用于公司里面所有应用程序的一项企业安全要求，甚至会出现在多家公司之间。CAS、SiteMinder和SAML等大多数SSO解决方案工作方式类似。在简单的SSO情形下，未通过验证的用户访问安全URL的请求被重定向至某个集中式网站进行登录（登录页面可能是本地页面）。成功登录后，随后的每个用户请求都会与验证令牌关联起来。用户浏览到该用户的安全背景还没有建立的不同网站后，服务器就会发送令牌给集中式验证服务器进行确认，获取属于该用户的身份（可能还有权限）。这个过程对用户来说是透明的，因为不需要进一步登录。 Acegi定义了一系列丰富的验证提供者: 内存中、JDBC、LDAP、JAAS、run-as、SiteMinder和CAS。内存中验证提供者可以在应用程序的开发阶段，在Spring配置文件中声明测试用户账户。JDBC和LDAP验证提供者的工作方式与Java EE平台中一样。JAAS验证提供者把验证请求委托给使用Java SE密封的Java验证和授权服务。SiteMinder和CAS验证提供者处理SSO验证请求。 run-as其实是一项授权特性，而不是验证提供者。作为Java EE中的一个授权配置选项，run-as在方法调用期间，暂时取代主体（用户）的原始安全角色; 而在Acegi中，run-as指定的角色是对主体的原始角色的一种补充。Java EE中的run-as在Java消息服务（JMS）中特别有用，因为JMS消息发送者的安全身份从不会传给接收者。run-as能够封装JMS消息处理，作为安全的业务处理逻辑的一部分。 Acegi中的并发会话控制这项出众特性可以满足实际的业务需求。它可以防止用户同时验证同一个应用程序的次数超过指定次数。 通道或传输层安全 许多Web应用程序面临的一个重大安全威胁就是会话劫持。HTTP协议基本上是无状态的，会话ID作为Web服务器用来跟踪与浏览器之间的状态通信的惟一措施。会话ID是ULR中的一个独特数字，表现为特殊的cookie或者令牌。如果会话劫持被认为是应用程序的一种重大风险，HTTPS 应用来保护服务器与浏览器之间的通信。客户端证书这种登录方式实际上执行了HTTPS通道安全，因为HTTPS传输的握手过程中使用了X509证书。对其他登录方式而言，通过HTTP通道进行传输是可选的。HTTPS传输中的消息加密及解密是开销很大的操作，延迟时间与HTTP消息的大小成正比，因而大多数商业网站通过HTTP进行传输; 一旦开始检查，就把客户重定向至HTTPS通道。 对使用SOAP Web服务的应用程序而言，除了通道安全外，应当为跨越企业边界的通信考虑采用消息层安全，这种机制可利用最新的XML数字签名和加密技术来保护一部分SOAP消息。 用户识别与授权 让经验丰富的Web编程人员编写脚本来模拟用户与网站之间的交互并不难。实际上，所有Web测试工具都是这样一种程序。 有时需要一个过滤器 作为实际的安全编程实践，服务器小程序过滤器可完成原本由许多不同Java beans才能分别完成的众多任务。有状态的Web应用程序、特别是个性化网站在进一步采取任何动作之前，常常需要对会话中用户的上下文信息进行初始化。有些网站会执行屏幕导航，不管用户的HTTP请求中的URL是什么。服务器小程序过滤器是职责链模式的实现，它极其适合这些用例。可以在过滤器类中编写逻辑，以便对用户的上下文信息进行初始化，或者使用REDIRECT，基于业务规则执行屏幕流程。对于使用JSF的应用程序，可以选择JSF阶段监听器，从而访问FacesContext对象。 CAPTCHA通常表现为含有失真字母以及数字的图像，它往往用于登录屏幕上，区别真实用户和计算机程序。尽管存在一些缺点，但CAPTCHA有助于缓解自动化计算机程序发起的某些类型的恶意攻击。JCAPTCHA是CAPTCHA技术的一种Java实现，可以融入到Java EE安全或者Acegi中。 一旦用户通过了验证，授权就会立即进行。 授权是根据业务规则来控制用户对应用程序资源访问的一种过程。用AOP术语来讲，授权是一种典型的横切关注点。因而，利用AOP技术实现授权是明智的。与验证相反，授权是出现在应用程序里面的一种局部过程。基于角色的访问控制（RBAC）也许是现代IT行业中采用最广泛的一种授权方案。角色代表应用程序里面定义的一组特权。实际上，角色必须映射成受制于同一些访问策略的一组用户。用户组通常在用户账户所在的同一个地方（如LDAP或者关系数据库）加以声明。 Java EE中的授权完全基于角色，而Acegi支持角色级别和身份级别的访问控制。在采用多层架构的应用程序中，授权可能会在不同级别进行，而且有着不同粒度。Java EE和Acegi中的授权服务通过名为授权提供者（authorization provider）的自定义安全模块来实现。 ● Web层中的授权 URL基于模式的安全（Web请求安全）是得到Java EE和Acegi支持的一种粗粒度的访问控制机制。其策略是，根据相应的URL来保护Web资源，那样设置访问控制策略相当简单。可以在配置文件中声明得到保护的ULR模式，那样一旦未验证的用户从未受保护的URL浏览到受保护的URL，服务器就会提出安全质询。用户通过验证后，服务器会对照访问控制策略里面声明的角色来检查用户的角色。如果没找到匹配的角色，用户会收到响应消息，报头中出现HTTP状态代码403。 在Java EE中，通过一些编程工作能够获得细粒度的用户界面组件级安全。服务器小程序API的isUserInRole ()方法以及JSP标准标签库（JSTL）标签可建立一直细化到每个HTML元素的访问控制机制。 ● beans中的授权 Acegi为Spring beans支持方法级安全，Java EE则为组成应用程序业务层（服务层）的Enterprise JavaBean（EJB）组件支持方法级安全。Acegi和许多Java EE容器使用AOP技术实现方法级安全。同时，依赖注入（又叫控制反转）使Spring beans和新的EJB 3.0企业beans具有POJO风格。因而，比较好的办法是使用干扰性较小的编程方法用于授权，譬如通过Spring上下文文件、EJB部署描述文件或者bean类文件内注释进行的配置。 ● 域对象实例中的授权 对某些应用程序、特别是遗留应用程序而言，最好为单个域对象实例（而不是域对象类）定义访问控制列表（ACL）。Acegi独家提供的域对象实例安全是粒度最细的访问控制机制，它可以利用整数位屏蔽、许可权限继承、JDBC支持的ACL存储库以及授权策略缓存机制，满足这个特殊的安全要求。 裁决 Acegi和大多数Java EE容器可以为同一个应用程序配置多个验证提供者和授权提供者。必须做出验证或者授权决定时，不同的提供者可能会同时适用，因而需要做出决定，防止出现冲突。裁决是指通过预定义算法来评估多个决定，从而做出裁决。裁决在Java EE规范中没有涉及，它由服务器开发商作为安全扩展件来实现。 在Acegi中，裁决在AccessDecisionManager 对象里面进行，这个对象有三种基本类型的实现: UnanimousBased、AffirmativeBased和ConsensusBased。与许多实际的表决系统一样，Acegi也定义了三种表决: 授权、否决和弃权。ConsensusBased实现根据非弃权表决的一致意见来授权或否决访问。如果得到了一个或者多个授权表决，AffirmativeBased实现就授权访问。UnanimousBased 实现则期待一致同意的授权表决，忽略弃权。 实际上，Java EE服务器开发商提供的自定义裁决实现的工作方式类似Acegi中的AccessDecisionManager。 考虑到在构建应用程序安全时有那么多的选项，所以除了应用程序性能、编程效率及代码可移植性等方面的严格准则外，决定还应当以业务需求为准绳。现在可以开始安全编程了。 安全编程 Acegi和Java EE 5都支持三种不同风格的安全编程: 编程性、声明性和注释性。考虑到Spring beans和EJB 3.0 beans具有的POJO性质，声明性安全和基于注释的安全是所需的非干扰性方法。 编程性安全嵌入在Java代码中，用于做出应用程序安全方面的决定。一般来说，由于API依赖项会打破POJO编程风格，编程性安全不是首选的。只有当单单声明性编程或者注释性编程不足以表示应用程序的安全模型时，才建议使用编程性安全。Acegi定义的Authentication对象由一个主对象和一系列GrantedAuthority对象组成。Acegi中的主对象比Java EE中的主对象来得灵活。它往往实现一个UserDetails接口，除了用户名外还有其他丰富信息，如用户的全名、电子邮件、地址、电话、传真和员工编号等。 声明性安全使用Java EE中的部署描述文件（web.xml和ejb-jar.xml）或者Acegi中的Spring XML配置文件，表示了Java代码外面应用程序的安全需求。它迫使开发者把精力集中在Java代码中的业务逻辑，促进POJO风格的编程。 Java 5中引入的注释又叫面向属性的编程，这种程序级标记技术可用来在类文件中把安全信息指定为元数据属性。应用程序部署后，Java EE运行环境或者Acegi就会获得元数据信息。它实际上是声明类型的安全。有了注释，就不需要维护部署描述文件之类的附属文件（side file）。而通常，一旦应用程序的源代码发生变化，附属文件的安全设置就要更新。 （计算机世界报 2007年7月9日 第26期 B22、B23）