security-constraint> 的子元素 <http-method> 是可选的,如果没有 <http-method> 元素,这表示将禁止所有 HTTP 方法访问相应的资源。
子元素 <auth-constraint> 需要和 <login-config> 相配合使用,但可以被单独使用。如果没有 <auth-constraint> 子元素,这表明任何身份的用户都可以访问相应的资源。也就是说,如果 <security-constraint> 中没有 <auth-constraint> 子元素的话,配置实际上是不起中用的。如果加入了 <auth-constraint> 子元素,但是其内容为空,这表示所有身份的用户都被禁止访问相应的资源。
web.xml:
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 四种认证类型:
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
一个是对该url-pattern没有进行role的限制
如:
对于tomcat而言,在org.apache.catalina.authenticator.AuthenticatorBase认证类中
子元素 <auth-constraint> 需要和 <login-config> 相配合使用,但可以被单独使用。如果没有 <auth-constraint> 子元素,这表明任何身份的用户都可以访问相应的资源。也就是说,如果 <security-constraint> 中没有 <auth-constraint> 子元素的话,配置实际上是不起中用的。如果加入了 <auth-constraint> 子元素,但是其内容为空,这表示所有身份的用户都被禁止访问相应的资源。
web.xml:
- <security-constraint>
- <display-name>
- baseporject</display-name>
- <web-resource-collection>
- <web-resource-name>baseproject</web-resource-name>
- <url-pattern>*.jsp</url-pattern>
- <url-pattern>*.do</url-pattern>
- <http-method>GET</http-method>
- <http-method>PUT</http-method>
- <http-method>HEAD</http-method>
- <http-method>TRACE</http-method>
- <http-method>POST</http-method>
- <http-method>DELETE</http-method>
- <http-method>OPTIONS</http-method>
- </web-resource-collection>
- <auth-constraint>
- <description>
- baseproject</description>
- <role-name>All Role</role-name>
- </auth-constraint>
- <user-data-constraint>
- <transport-guarantee>NONE</transport-guarantee>
- </user-data-constraint>
- </security-constraint>
- <login-config>Xml代码
-
- <!--四种验证方式,附在最后有说明-->
- <auth-method>FORM</auth-method>
- <form-login-config>
- <form-login-page>/login.html</form-login-page>
- <form-error-page>/error.html</form-error-page>
- </form-login-config>
- </login-config>
- <security-role>
- <role-name>All Role</role-name>
- </security-role>
-
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 四种认证类型:
- BASIC:HTTP规范,Base64
- <web-app>
- ......
- <login-config>
- <auth-method>BASIC</auth-method>
- </login-config>
- ......
- </web-app>
- DIGEST:HTTP规范,数据完整性强一些,但不是SSL
- <web-app>
- ......
- <login-config>
- <auth-method>DIGEST</auth-method>
- </login-config>
- ......
- </web-app>
- CLIENT-CERT:J2EE规范,数据完整性很强,公共钥匙(PKC)
- <web-app>
- ......
- <login-config>
- <auth-method>CLIENT-CERT</auth-method>
- </login-config>
- ......
- </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
- <form name="loginform" method="post" action="j_security_check">
- <INPUT name="j_username" type="text">
- <INPUT name="j_password" TYPE="password">
- <input type="submit" value="登 录" >
- </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
如:
- <security-constraint>
- <web-resource-collection>
- <web-resource-name>test2</web-resource-name>
- <url-pattern>/*</url-pattern>
- </web-resource-collection>
- <auth-constraint>
- <role-name>tomcat1</role-name>
- </auth-constraint>
- </security-constraint>
一个是对该url-pattern没有进行role的限制
如:
- <security-constraint>
- <web-resource-collection>
- <web-resource-name>test3</web-resource-name>
- <url-pattern>/*</url-pattern>
- </web-resource-collection>
- </security-constraint>
对于tomcat而言,在org.apache.catalina.authenticator.AuthenticatorBase认证类中
- /**
- * Enforce the security restrictions in the web application deployment
- * descriptor of our associated Context.
- *
- * @param request Request to be processed
- * @param response Response to be processed
- *
- * @exception IOException if an input/output error occurs
- * @exception ServletException if thrown by a processing element
- */
- @Override
- public void invoke(Request request, Response response)
- throws IOException, ServletException {
- ....
- // Since authenticate modifies the response on failure,
- // we have to check for allow-from-all first.
- //
- boolean authRequired;
- if (constraints == null) {
- authRequired = false;
- } else {//有安全限制
- authRequired = true;
- for(i=0; i < constraints.length && authRequired; i++) {
- if(!constraints[i].getAuthConstraint()) {//如果不需要认证限制
- authRequired = false;//则不需要认证
- } else if(!constraints[i].getAllRoles()) {//如果不是*,即所有角色的话
- String [] roles = constraints[i].findAuthRoles();
- if(roles == null || roles.length == 0) { //只要此url-pattern有一个限制没有控制角色,则满足次url-pattern的url可以被任意角色和匿名用户访问
- authRequired = false;//则不需要认证
- }
- }
- }
- }
- ......
结论
所以按照上面同时配置同一个url-pattern,不同安全限制,只要有一个不限制角色,则此url-pattern不受角色限制,满足次url-pattern的url可以被任意角色和匿名用户访问