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

标签：blank   数据   desc   技术分享   pat   定义   灵活   规则   标记   

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元素的对决

`

1. 合并单个的角色名时，所列的所有角色名都允许访
   问;
2. 角色名“*”与其他设置合少t–时，所有人都允许访
   问;
3. 空的(空的不是没有)auth-constraint标记与其他设置合并时，所有人都不允许访问!换句话说，空的auth-constraint就是最后“宣判”!
4. 如果某个security-constraint素没有auth-constraint元素，它与其他设置合并时，所有人都允许访问。
   `

   两个不同的非空auth-constraint元素应用于同一个受限资源，那么两个auth-constraint元素中所有角色的并集都运行访问。
   受限访问，指的是客户不能访问，但是Web应用的其他部分时可以的。
   

看看认证

• 4中认证类型
  基本认证、摘要认证、客户证书认证和表单认证。
• 实现认证
  在DD中声明认证机制，主要是login-config元素
  

认证类型小结

基于表单的认证

表单登录，可以定制自己的登录表单页面，而不是用其他3中认证所有的浏览器登录窗口。

表单登录安全保证：HTTPS

要实现数据机密性和/或完整性时，J2EE规范可以保证所传输的数据会经过一个“有保护的传输层连接”，即容器不必使用任何特定的协议来处理安全传输。（实际中几乎都会使用SSL之上的HTTPS协议。）
数据保护要有一些开销，且不会对应用中的每个请求和响应都加密，因此使用——以声明方式保守地实现数据机密性和完整性：

数据保护

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

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

标签：blank   数据   desc   技术分享   pat   定义   灵活   规则   标记   

原文地址：http://www.cnblogs.com/myitroad/p/6192536.html