devbox
神奇cpp
这个屌丝很懒，什么也没留下！
关注作者
热门标签
热门文章
当前位置:   article > 正文

web.xml中和四种认证类型

作者：神奇cpp | 2024-08-10 00:26:40

赞

踩

security-constraint
security-constraint> 的子元素 <http-method> 是可选的，如果没有 <http-method> 元素，这表示将禁止所有 HTTP 方法访问相应的资源。 
子元素 <auth-constraint> 需要和 <login-config> 相配合使用，但可以被单独使用。如果没有 <auth-constraint> 子元素，这表明任何身份的用户都可以访问相应的资源。也就是说，如果 <security-constraint> 中没有 <auth-constraint> 子元素的话，配置实际上是不起中用的。如果加入了 <auth-constraint> 子元素，但是其内容为空，这表示所有身份的用户都被禁止访问相应的资源。 
web.xml:  
Xml代码   收藏代码
  1.   
  2. <security-constraint>   
  3.   <display-name>   
  4.   baseporject</display-name>   
  5.   <web-resource-collection>   
  6.    <web-resource-name>baseproject</web-resource-name>   
  7.    <url-pattern>*.jsp</url-pattern>   
  8.    <url-pattern>*.do</url-pattern>   
  9.    <http-method>GET</http-method>   
  10.    <http-method>PUT</http-method>   
  11.    <http-method>HEAD</http-method>   
  12.    <http-method>TRACE</http-method>   
  13.    <http-method>POST</http-method>   
  14.    <http-method>DELETE</http-method>   
  15.    <http-method>OPTIONS</http-method>   
  16.   </web-resource-collection>   
  17.   <auth-constraint>   
  18.    <description>   
  19.    baseproject</description>   
  20.    <role-name>All Role</role-name>   
  21.   </auth-constraint>   
  22.   <user-data-constraint>   
  23.    <transport-guarantee>NONE</transport-guarantee>   
  24.   </user-data-constraint>   
  25. </security-constraint>   
  26. <login-config>Xml代码   

  28. <!--四种验证方式,附在最后有说明-->    
  29.   <auth-method>FORM</auth-method>    
  30.   <form-login-config>    
  31.    <form-login-page>/login.html</form-login-page>    
  32.    <form-error-page>/error.html</form-error-page>    
  33.   </form-login-config>    
  34. </login-config>    
  35. <security-role>    
  36.   <role-name>All Role</role-name>    
  37. </security-role>    
  38.   



    security-constriaint元素的用途是用来指示服务器使用何种验证方法了.此元素在web.xml中应该出现在login-config 的紧前面。它包含是个可能的子元素，分别是：web-resource-collection、auth-constraint、user-data- constraint和display-name。下面各小节对它们进行介绍。 
1. web-resource-collection 
  此元素确定应该保护的资源,所有security-constraint元素都必须包含至少一个web-        resource-collection项.此元素由一个给出任意标识名称的web-resource-name元素、一个确定应该保护URL    的url-pattern元素、一个指出此保护所适用的HTTP命令（GET、POST等，缺省为所有方法）的http-method元素和一个提供资料 的可选description元素组成。 
    重要的是应该注意到，url-pattern仅适用于直接访问这些资源的客户机。特别是，它不适合于通过MVC体系结构利用RequestDispatcher来访问的页面，或者不适合于利用类似jsp:forward的手段来访问的页面。 
2. auth-constraint  
元素却指出哪些用户应该具有受保护资源的访问权。此元素应该包含一个或多个标识具有访问权限的用户类别role-name元素，以及包含（可选）一个描述角色的description元素。 
3. user-data-constraint 
这个可选的元素指出在访问相关资源时使用任何传输层保护。它必须包含一个transport-guarantee子元素（合法值为NONE、 INTEGRAL或CONFIDENTIAL），并且可选地包含一个description元素。transport-guarantee为NONE值将 对所用的通讯协议不加限制。INTEGRAL值表示数据必须以一种防止截取它的人阅读它的方式传送。虽然原理上（并且在未来的HTTP版本中），在 INTEGRAL和CONFIDENTIAL之间可能会有差别，但在当前实践中，他们都只是简单地要求用SSL。 
4 四种认证类型： 

Xml代码   收藏代码
  1. BASIC：HTTP规范，Base64   
  2. <web-app>   
  3.     ......   
  4.     <login-config>   
  5.         <auth-method>BASIC</auth-method>   
  6.     </login-config>   
  7.     ......   
  8. </web-app>   
  9.   
  10. DIGEST:HTTP规范，数据完整性强一些，但不是SSL   
  11. <web-app>   
  12.     ......   
  13.     <login-config>   
  14.         <auth-method>DIGEST</auth-method>   
  15.     </login-config>   
  16.     ......   
  17. </web-app>   
  18.   
  19. CLIENT-CERT：J2EE规范，数据完整性很强，公共钥匙（PKC）   
  20. <web-app>   
  21.     ......   
  22.     <login-config>   
  23.         <auth-method>CLIENT-CERT</auth-method>   
  24.     </login-config>   
  25.     ......   
  26. </web-app>   

FORM：J2EE规范，数据完整性非常弱，没有加密，允许有定制的登陆界面。 
<web-app> 
    ...... 
    <login-config> 
        <auth-method>FORM</auth-method> 
        <form-login-config> 
            <form-login-page>/login.html</form-login-page> 
            <form-error-page>/error.jsp</form-error-page> 
        </form-login-config> 
    </login-config> 
    ...... 
</web-app> 
这里的 FORM 方式需要说明的是 登录页面的固定的元素:login.html 

Html代码   收藏代码
  1. <form name="loginform" method="post" action="j_security_check">   
  2.   
  3. <INPUT name="j_username" type="text">   
  4.   
  5. <INPUT name="j_password" TYPE="password">   
  6.   
  7. <input type="submit" value="登 录" >   
  8.   
  9. </form>   

form 的action 必须是j_security_check, method="post", 用户名 name="j_username" , 密码name="j_password"  这些都是固定的元素 。

对于同一个url-pattern,在web.xml出现2个<security-constraint>，一个是对该url-pattern进行了role的限制，一个没有限制role，会如何？


实践

一个是对该url-pattern进行了role的限制，即配置auth-constraint

如：

[html]  view plain copy
  1. <security-constraint>  
  2.     <web-resource-collection>  
  3.       <web-resource-name>test2</web-resource-name>  
  4.       <url-pattern>/*</url-pattern>  
  5.     </web-resource-collection>  
  6.     <auth-constraint>  
  7.        <role-name>tomcat1</role-name>  
  8.     </auth-constraint>  
  9.   </security-constraint>   


    
一个是对该url-pattern没有进行role的限制
如：
 
 
[html]  view plain copy
  1. <security-constraint>  
  2.     <web-resource-collection>  
  3.       <web-resource-name>test3</web-resource-name>  
  4.       <url-pattern>/*</url-pattern>  
  5.     </web-resource-collection>  
  6.     
  7.   </security-constraint>   


  
  
对于tomcat而言，在org.apache.catalina.authenticator.AuthenticatorBase认证类中
[java]  view plain copy
  1. /** 
  2.      * Enforce the security restrictions in the web application deployment 
  3.      * descriptor of our associated Context. 
  4.      * 
  5.      * @param request Request to be processed 
  6.      * @param response Response to be processed 
  7.      * 
  8.      * @exception IOException if an input/output error occurs 
  9.      * @exception ServletException if thrown by a processing element 
  10.      */  
  11.     @Override  
  12.     public void invoke(Request request, Response response)  
  13.         throws IOException, ServletException {  
  14.     
  15.     
  16.   ....  
  17.             // Since authenticate modifies the response on failure,  
  18.         // we have to check for allow-from-all first.  
  19.         //  
  20.         boolean authRequired;  
  21.         if (constraints == null) {  
  22.             authRequired = false;  
  23.         } else {//有安全限制  
  24.             authRequired = true;  
  25.             for(i=0; i < constraints.length && authRequired; i++) {  
  26.                 if(!constraints[i].getAuthConstraint()) {//如果不需要认证限制  
  27.                     authRequired = false;//则不需要认证  
  28.                 } else if(!constraints[i].getAllRoles()) {//如果不是*，即所有角色的话  
  29.                     String [] roles = constraints[i].findAuthRoles();  
  30.                     if(roles == null || roles.length == 0) { //只要此url-pattern有一个限制没有控制角色，则满足次url-pattern的url可以被任意角色和匿名用户访问  
  31.                         authRequired = false;//则不需要认证  
  32.                     }  
  33.                 }  
  34.             }  
  35.         }        
  36.           
  37.           
  38.    ......  

结论

所以按照上面同时配置同一个url-pattern，不同安全限制，只要有一个不限制角色，则此url-pattern不受角色限制,满足次url-pattern的url可以被任意角色和匿名用户访问



声明：本文内容由网友自发贡献，不代表【wpsshop博客】立场，版权归原作者所有，本站不承担相应法律责任。如您发现有侵权的内容，请联系我们。转载请注明出处：https://www.wpsshop.cn/w/神奇cpp/article/detail/955847
推荐阅读
相关标签

Copyright © 2003-2013 www.wpsshop.cn 版权所有，并保留所有权利。

  

闽ICP备14008679号