Web应用的前景是在不断的演进中的，它已经从最开始作为共享文档和信息的方式演化为业务治理的平台，而在这种应用中，许可和授权是一个要害的特征。Web的应用前景还在不断的演进中，而本文把关注放在面向群体的应用中，例如博可和维基。在这种应用中，由于作者希望有交流和反馈，所以授权不是非常严格的。有时，由于害怕识别，会造成失去一些人可能做出的贡献。但是，缺少授权就会带来诸如垃圾邮件这类的问题。这里有几条在Web上抽取的信息：
·我认为在维基上垃圾邮件是不可避免的。我建立了这个网站维基的一部分，把修改权限
平开放给每个人，以鼓励读者和来访者互相交流。但是，这已经是第二次了，一个发垃圾邮件的人把一堆到中国网站的链接放在这的网页里。（摘自X-Pollen）
·“致所有在维基上发垃圾邮件的人：从1-2-2005起，任何人要做任何操作，包括编辑或增加新页，都要由搜索引擎强制间隔十个小时。由于在这个网站上发的垃圾邮件在一分钟、最多一小时内就会被删除，所以，任何试图在这个网站上建立发垃圾邮件的机制都是徒劳的举动。（摘自C2 Wiki）”
很明显，垃圾邮件发送源必须被识别出来。大多数者类恶意的攻击发生数据匹配模式被识出来之后。一个可能的方法是人工而不是有计算机来停止这种攻击，很显然这是个挑战。通过图灵测试，按一个有名的计算机专家――阿兰。图灵命名的试验，可以确定机器能够实现类似人类操作的能力。者类测试中最有名的一个是CAPTCHA (an acronym for completely automated public Turing test to tell computers and humans apart)。这个测试常用来表明以个典型的情况：混乱或含义模糊的词，人很轻易识别，但对于光学识别软件来讲却很困难。
图1是一个典型的CAPTCHA.
图1一个典型的CAPTCHA.
现在，大多数主要的服务提供商(Yahoo, Hotmail, Google)已经在他们的免费服务中使用CAPTCHA，用来作为区分垃圾邮件和虚假注册的手段。在本文中，我们要描述以下在我们的Web应用中加入基于CAPTCHA授权的方法。
首先，我们快速浏览以下J2EE中Web应用的安全模型。
J2EE安全模型
在java开发中，安全性始终是一个最受关注的领域。毫无疑问，J2EE在构建安全的应用时，采用了同样的原理和健壮的框架。在J2EE中，安全性是一个很大的题目，在这里是不可能叙述细节的。在这方面有好多好的资源。我极力推荐团队和个人花些时间来熟悉这些概念。在这力，我只能极概括的叙述一些最要害的概念。
要害概念
在J2EE应用中，安全性必须采用声明或编程的话方法。就象名字中暗示的，当采用声明方法时，开发者在应用软件代码的外部定义用于应用的安全性约束。这些声明用部署描述符的形式来建造(web.xml， ejb-jar.xml)，并由容器的运行环境来保证它的强制执行。声明的方式容许开发者：
·能够实现基于身份的对资源存取的约束（例如：/admin/* 只能容许有治理员身份的人来操作）
·能够实现对某些URL的存取只能用某种协议的约束（例如：“/customer/*”只能通过HTTPS来访问）
·能够实现基于身份的对某些服务存取的约束（例如：可以限定SiteShutdownServlet只能由具有“god”身份的人来操作）
·能够实现当用户要存取某些受限资源但用户还没有登录到系统的时候，自动重定向到登录页面的功能.而编程的方法能提供查询和调用安全设施的机制，而开发者必须实现这些机制。这个方法的特点是：
·检索出与当前用户相关联的部分：HttpServletRequest.getUserPRincipal or EJBContext.getCallerPrincipal
·查询用户是否具有某种特定的身份：HttpServletRequest.isUserInRole(String role) or EJBContext.isCallerInRole(String role)
这两种方法都有它的局限性，并且是能互相补充的。
Web应用的声明安全的方法
Web应用的声明安全的方法本质上是一种被动的方法。这意味者只有在刚开始访问受保护资源的用户，假如他们没有被受权，才会被重定向到登录页面。假如这个用户已经被授权并有适当的权限，他们就能访问这些资源。
这类方法中有一个最常用的方法是基于规则的受权。应用部署描述符web.xml分两个部分描述了在这个方法中需要的所有元素。
第一部分是适用于整个应用的。它要鉴别出：
·在登录中需要使用的方法。J2EE支持BASIC，DIGEST，FORM，或CERT等几种授权机制。
·用于基于规则受权的登录和错误的页面
·能在应用中使用的所有身份的超集
图2表明了第一部分的要害元素和它们之间的关系
图2 第一部分的要害元素和它们之间的关系
第二部分说明了资源方面的约束。部署描述符可以包含零个或多个类似于下面的声明：
·需要保护的站点。这可以在web-resource-collection内使用url-pattern来配置。
·能够存取资源的身份的集合(auth-constraint)。它通常是第一部分定义的身份集合的一个子集。
·与某个资源相关的传输的保证(user-data-constraint)。
图3表明了第二部分的要害元素和它们之间的关系
图3 第二部分的要害元素和它们之间的关系
现在，我们看一个简单的例子web.xml:
<web-app>
<!-- ... -->
<!--
Define the security constraint. This will limit the /admin/* portion of
the application to only be accessible to users within the "admin" role.
When an unauthenticated user attempts to access this section of the site,
they will be automatically presented with the login page.
-->
<security-constraint>
<!-- Define the context-relative URL(s) to be protected -->
<web-resource-collection>
<web-resource-name>Protected Area</web-resource-name>
<url-pattern>/admin/*</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
</web-resource-collection>
<!-- Define the roles that are allowed to access this URL with the given methods -->
<auth-constraint>
<role-name>admin</role-name>
</auth-constraint>
<!-- Transport guarantee could be used to guarantee an HTTPS protocol -->
<user-data-constraint>
<transport-guarantee>NONE</transport-guarantee>
</user-data-constraint>
</security-constraint>
<!--
Define the method for authenticating a user when requesting a restricted
page. Methods include BASIC (the simple pop-up dialog), FORM and
CERTIFICATE.
-->
<login-config>
<!-- We will use form based authentication -->
<auth-method>FORM</auth-method>
<realm-name>Default Realm</realm-name>
<!-- where should the user be forwarded to enter his credentials -->
<form-login-config>
<form-login-page>/login/login.jsp</form-login-page>
<!--
On error the user will be shows this page It can also server side
forward back to the login page, which is popular behavior for most
sites.
-->
<form-error-page>/login/error.jsp</form-error-page>
</form-login-config>
</login-config>
<!--
Finally a list of all security roles in the application must be given.
-->
<security-role>
<description>Capable of administrating the site</description>
<role-name>admin</role-name>
</security-role>
</web-app>
这个简单的部署描述符包含以下几部分的安全配置：
·约束对有以/admin/*模式开头的URLs的存取（URLl模式）
·在/admin下的资源只能使用HTTP GET或POST来存取(HTTP方法)
·资源能在标准的HTTP连接方式下提供服务（传输保证）
·只有具有治理员身份的用户才能存取这些资源（身份命名）
·对远程用户使用基于规则的授权（授权方法）
·给用户显示一个登录的页面――/login/login.jsp ，以便用户输入信息来确认身份（形成登录页面）
·假如在授权过程中发生错误，给用户显示以个页面来提示出错――/login/error.jsp（形成出错页面）
扩展一个容器的安全设施
JAAS（Java Authentication and Authorization Services)实现了一个JAVA应用的可插入性授权模块（PAM）。它容许平行开发安全部分和应用部分。开发者可以从这些选项中选择并在应用中配置。由于容许与应用平行开发，所以JAAS有一些优点，还可以促进它在不同的应用中重用。
JAAS在应用的服务端也同样有价值。然而，JAAS在J2EE中并没有取得同样的成功。直到最近，才开放了一些可定制的API用于扩展安全设施。但情况在改变。应用的服务端现在提供了适配器，可以容许把JAAS整合近已有的安全设施。这种整合仍然是与具体的应用相关的，并且非常复杂。
Tomcat提供了一种使用JAAS的相当简单和直接整合的方法。用户登录模块是用配置文件来配置的（Tomcat realm configuration and the standard JAAS configuration）。当服务端需要调用登录模块时，它把所有的请求都路由到org.apache.catalina.realm.JAASRealm适配器。把JAAS整合进Tomact的细节可参考相应的资料Resources。
在这篇文章，我们实现了一个JAAS模块，并把它整合近Tomcat服务端，以提供J2EE的安全解决方案。
解决方法
在叙述实现方面之前，先描述一下解决方案的目标和所用的方法。
目标：
·为Web应用提供一种较弱的授权机制。这里，较弱的授权机制的含义是安全模块或应用不区分用户是否是在远程访问。
·不要求每个用户在系统中有惟一的一个标识（登录名）。这可以对远程用户做一定的隐藏。
·这种授权机制能区分计算机和用户，这样可以防止垃圾邮件的源自动登录并滥用资源。我们用CAPTCHAs来做测试。
·这个授权机制应该基于J2EE的安全模型。我们要避免与这个模型不一致的方法。
根据以上的目标，很显然，我们要保证每次会话中都是由实际的用户参与的。应用的服务端治理会话来保持用户的状态。当一个未授权的用户访问受保护的资源的时候，J2EE的安全模块要把用户转到登录页面。这个登录页面产生以个惟一的CAPTCHA并把它与用户的会话联系起来。这个登录页面就以一幅图像的形式显示这个CAPTCHA，并要求用户识别这幅图像。这个登录页面还有一个包含当前会话ID的隐藏起来的输入域。
用户把自己识别的结果添入输入域并提交。在得到反馈后，负责登录的模块取出对话的ID和用户的反馈。然后，把反馈与这个会话相关联的CAPTCHA相比较。假如匹配，那么这个对这个用户的鉴别就通过了，并把这个用户的身份定为anonymous。
在授权后，远端的用户就可以以anonymous用户的身份来存取所有受保护的资源。
图4说明了我们的方法
图4 我们的方法
实现
实现一个新授权机制的过程是相当明了的。整个过程可分为四个过程：
·保护Web资源
·为每个会话产生以个惟一的标识
·与已有的安全容器整合
·测试
下面具体叙述以下这些过程。
保护Web资源
Web资源保护用J2EE声明安全机制。下面的是web.xml文件的一个片断，显示了如何实现要求的配置。
<?xml version="1.0" encoding="ISO-8859-1"?>
<web-app>
<!-- constrain a section of the site -->
<security-constraint>
<display-name>Anonymous Security Constraint</display-name>
<web-resource-collection>
<web-resource-name>Protected Area</web-resource-name>
<url-pattern>/security/protected/*</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>anonymous</role-name>
</auth-constraint>
</security-constraint>
<!-- Default login configuration uses form-based authentication -->
<login-config>
<auth-method>FORM</auth-method>
<realm-name>Anonymous Form-Based Authentication Area</realm-name>
<form-login-config>
<form-login-page>/security/protected/login.jsp</form-login-page>
<form-error-page>/security/protected/error.jsp</form-error-page>
</form-login-config>
</login-config>
<!-- Security roles referenced by this web application -->
<security-role>
<role-name>anonymous</role-name>
</security-role>
<!-- The Usual Welcome File List -->
<welcome-file-list>
<welcome-file>index.jsp</welcome-file>
</welcome-file-list>
</web-app>
