serlvet安全的4大要素
认证、授权、机密性和数据完整性。
容器完成认证和授权的过程
代码中不要有安全信息
大多数Web应用，大多数情况下Web应用的安全约束都应该以声明方式处理，即在部署描述文档中指定。原因如下：
谁不想更多地采用XML呢
通常能自然地映射到公司IT部门现有的任务角色
你可以用更灵活的方式使用以前servlet
应用开发人员可以重servlet不用去碰源代码
随着应用的扩展，可以减少可能的维护
还有一点，这正好能体现容器的价值
支持基于组件的开发思想
谁来实现Web应用中的安全？
-servlet提供者只需要关注业务
- 应用管理员只需要确定应用中有哪些角色（如tomcat中的conf/tomcat-users.xml）
- 主要任务由部署人员承担：确定哪些角色可以访问哪些servlet
授权的步骤
- 安全领域
安全领域即存储认证信息的地方，如tomcat的tomcat-users.xml会在启动时读入内存，则成为内存领域。（测试时可以在该文件存放角色认证信息，生产环境则一般不推荐，而是用LDAP或关系数据库存放）。 - tomcat-users.xml文件
- 启动认证
要让容器询问用户名和口令，需要在DD中如下配置，才能进行认证：
授权第一步：定义角色
把开发商（Tomcat）特定的“用户”文件的角色映射到部署描述文件中建立的角色。
如开发商特定的tomcat-users.xml中的role元素：
以及servlet规范：web.xml中的DD security-role元素：
授权第二步：定义资源/方法约束security-constraint
以声明的方式指定一个给定的资源/方法组合中能由特定角色的用户所访问。
在DD的security-constraint元素：
关于security-constraint子元素web-resource-collection的要点：
<web-resource-collection>元素有两个主要的子元素:url-pattern(一个或多个)和http-method(可选，0个或多个)；
URL模式和HTTP方法一同定义受限资源请求；
web-resource-name元素是必要的，就算你自己可能不会用它(可以认为它要由IDE使用，或留待将来使用)；
description元素是可选的；
url-pattern元素使用servlet标准命名和映射规则(有关URL模式的详细内容可以去看关于“部署’那一章)；
必须至少指定一个url-pattern，不过也可以有多个；
http-method元素的合法方法包括:GET、POST、PUT、TRACE、DELETE、HEAD和OPTIONS；
如果没有指定任何HTTP方法，那么所有方法都是受约束的!!；
如果确实指定了http-method，则只有所指定的方法是受约束的。换言之，一旦指定了一个http-method,就会自动使未指定的HTTP方法不受约束；
一个security-constraint中可以有多个web-resource-collection元素；
auth-constraint元素应用于security-constraint中的所有web-resource-collection元素。
auth-constraint元素并不是定义哪些角色可以访问web-resource-collection中的资源，相反，它只是定义了哪些角色可以做出受约束的请求。
关于security-constraint子元素auth-constraint子元素：
auth-constraint规则：
在security-constraint元素中，auth-constraint元素是可选的；
如果存在一个auth-constraint，容器必须对相关URL进行认证；
如不存在auth-constraint，容器运行不经认证就能访问这些URL；
为提高可读性，可以在auth-constraint中增加一个description元素。
role-name规则：
在auth-constraint元素中，role-name元素是可选的；
如果存在role-name元素，它们会告诉容器哪些角色得到许可；
如果存在一个auth-constraint元素，但是没有任何role-name子元素，那么所有用户都遭到拒绝；
如果有<role-name>*</role-name>，那么所有用户都是允许的；
角色名区分大小写。
多个security-constraint/auth-constraint元素的对决
`
- 合并单个的角色名时，所列的所有角色名都允许访
问; - 角色名“*”与其他设置合少t–时，所有人都允许访
问; - 空的(空的不是没有)auth-constraint标记与其他设置合并时，所有人都不允许访问!换句话说，空的auth-constraint就是最后“宣判”!
- 如果某个security-constraint素没有auth-constraint元素，它与其他设置合并时，所有人都允许访问。
`两个不同的非空auth-constraint元素应用于同一个受限资源，那么两个auth-constraint元素中所有角色的并集都运行访问。
受限访问，指的是客户不能访问，但是Web应用的其他部分时可以的。
看看认证
- 4中认证类型
基本认证、摘要认证、客户证书认证和表单认证。 - 实现认证
在DD中声明认证机制，主要是login-config元素
认证类型小结
基于表单的认证
表单登录，可以定制自己的登录表单页面，而不是用其他3中认证所有的浏览器登录窗口。
表单登录安全保证：HTTPS
要实现数据机密性和/或完整性时，J2EE规范可以保证所传输的数据会经过一个“有保护的传输层连接”，即容器不必使用任何特定的协议来处理安全传输。（实际中几乎都会使用SSL之上的HTTPS协议。）
数据保护要有一些开销，且不会对应用中的每个请求和响应都加密，因此使用——以声明方式保守地实现数据机密性和完整性：
数据保护
- 未经认证的客户请求一个没有传输保证的受限资源
- 未经认证的客户请求一个受限资源，这个资源有机密性传输保证
