二、验证的类型
1、HTTP Basic验证
  HTTP的基本验证。它是由HTTP1.1规范定义的，是一种保护资源的最简单和最常用的验证机制。当浏览器请求任何受保护的资源时，服务器都要求一个用户名和口令。只有用户输入了合法的用户名/口令，服务器才发送资源。

2、HTTP Digest验证
  HTTP摘要验证。除了口令是以加密的方式发送，其他与基本验证一样。
  优点：比基本验证安全。
  缺点：只能被IE5以上版本支持，许多Servlet容器不支持。

3、FORM-Based验证
  基于表单的验证。它类似于基本验证，但它使用用户自定义的表单来获得用户名和口令。开发时必须创建包含表单的HTML页面。

4、HTTPS Client验证
  客户证书验证。它采用HTTPS传输信息。HTTPS是在安全套接层之上的HTTP，SSL可以保证Internet上敏感数据传输的保密性。在这种机制中，当浏览器和服务器之间建立起SSL连接后，所有的数据都以加密的形式传输。
  优点：是这几种验证中最安全的。所有常用的浏览器都支持这种验证。
  缺点：它需要一个证书授权机构。

三、基本验证过程
客户请求一个受保护资源时，浏览器和Web容器之间实现身份验证的过程：
  1）浏览器向某个受保护资源(Servlet或JSPP)发送请求。此时，浏览器并不知道资源是受保护的，所以它发送的请求是一般的HTTP请求，如：

GET/login.do HTTP/1.1
1
  2）当服务器接收到对资源的请求后，首先在访问控制列表(ACL)中查看该资源是否是受保护的资源。如果不是，服务器将该资源发送给用户；如果是，它并不直接发送该资源，而是向客户发送一个401 Unauthorized(非授权)消息。在该消息中包含一个响应头告诉浏览器访问该资源需要验证。响应消息中还包括验证方法和安全域名称以及请求内容的长度和类型。

  3）当浏览器收到响应消息后，打开一个对话框提示输入用户名和密码。

  4）当服务器收到该请求，它将访问访问控制列表中检验用户名和密码，如果是合法用户且该用户可以访问该资源，它将发送资源并在浏览器中显示出来；否则，它将再一次发送401 Unauthorized消息，浏览器再一次显示用户名/密码对话框。

四、声明式安全与编程式安全
  1）声明式安全：是一个应用程序的安全结构，包括角色、访问控制及验证需求都在应用程序外部表示。在应用程序内通过部署描述文件(web.xml)声明安全约束。它仅能针对URL来设置哪些资源必须受到保护。
  2）编程式安全：主要使用HttpServletRequest接口中的有关方法实现。

五、用户与角色
  每个用户可以拥有一个或多个角色，每个角色限定了可访问的Web资源。在Web应用中，对资源的访问权限一般是分配给角色而不是实际的用户。一个用户可以访问其拥有的所有角色对应的Web资源。

安全域模型的使用

1）定义角色、用户以及用户与角色的映射

tomcat-users.xml：

1.<tomcat-users>
2.       <role rolename="xxxx" />
3.        <role rolename="xxxx"/>
4.        ……
5.        <user username="xxxx" password="xxxx" />
6.        <user username="xxxx" password="xxxx" roles="xxxx"/>
7.</tomcat-users>        

注意：在tomcat-users.xml中添加或者修改就鄂塞和用户后需要重新启动tomcat。

2）定义安全约束
（1） <security-constraint> 定义受保护的Web资源集合、访问资源的角色以及用户数据的约束

① <web-resource-collection> 定义一个或者多个Web资源集合
② <auth-constraint> 指定可以访问受限资源的角色
③ <user-data-constraint> 指定数据应该如何在客户与服务器之间传输
④

（2）<login-config> 元素 定义使用的验证机制。验证机制不同，当Web客户访问受保护的Web资源时，系统弹出的对话框不同
（3）<security-role>元素 用来定义安全约束中引用的所有角色名