《Head First Servlets & JSP》-12-Web应用安全

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协议。）

数据保护要有一些开销，且不会对应用中的每个请求和响应都加密，因此使用——以声明方式保守地实现数据机密性和完整性：

数据保护

未经认证的客户请求一个没有传输保证的受限资源
未经认证的客户请求一个受限资源，这个资源有机密性传输保证