web安全

一、打开认证:
<login-config>
     <auth-method>认证类型</>
</>

如果使用FORM形式,

数据完整性非常弱,没有加密,允许有定制的登陆界面。

配置如下:

<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"  这些都是固定的元素

以上来源

二、设置好认证方式后,在web.xml下配置资源约束:
<security-constraint>                                 
     <web-resource-collection>                可以有多个resource-collection,但只对应一个auth-constraint
         <web-resource-name>xxxx</>   由工具使用,别的地方不会见到这个名字,但它是必要的
         <url-pattern>/Beer/AddBeer/*</>
         <http-method>GET</>                如果不写此项,则所有请求方式都可以访问,写了就只允许写的方式
     </web-resource-collection>
     <auth-constraint>                                   authorization授权约束
         <description>可选的,用于增加可读性</>
         <role-name></role-name>             指定的角色才可以访问上面的内容,不写则所有角色请求都会拒绝
     </auth-constraint>
 </security-constraint>

注意:
1. <security-constraint>本身可以有多个。
2.<role-name>*</role-name>|没有<auth-constraint>   所有角色认证后可访问
3.有<auth-constraint>没有<role-name>则所有角色都不可访问
多个<security>中,有相同url-pattern的合并规则
1.如果存在空的<auth-constraint>,则所有用户不可访问
2.取多个<auth-constraint>中最大的范围:并集

Servlet规范对程序式安全的支持:
    1.用户通过http的401认证
    2.servlet中,在httpRequest上调用isUserInRole("XXX");
    3.此时容器会拿这个XXX去DD中(security-role下)寻找,是否存在一个role-name为XXX的安全角色
    4.存在则返回true,否则false
    5.DD中还可以指定<security-role-ref>(<role-name>&<role-link>)不必与tomcat-users.xml中完全一致
    6.寻找时,先查ref,如果找到就返回,因此如果ref和security-role重名,则找到的是ref

三、要在自定义表单的基础上对传输的数据进行加密,需要使用https:
在security-constraint中进行声明,则容器自动实现数据加密。但是,并非所有的数据都有加密的必要,为了提升性能,我们需要进行如下操作:
①声明一个security-constraint,并指定这个安全约束的web-resource-collection。
②声明user-data-constraint,
     默认是NONE,不进行数据保护;
     使用INTEGRAL(完整的),会保证数据在传输过程中不能被修改(一般用shar1等实现,最后检查一致性);
     使用confidential(机密的),会对数据进行加密。
完整例子:

零、未认证用户请求受限资源的过程:
①客户发起请求,容器检查web.xml,发现这个资源是security-constraint中的,并且要求了数据保密性( transport-guarantee   CONFIDENTIAL)。
②容器向客户发回301重定向响应,要求用户 以https进行访问。
301(永久移动)请求的网页已永久移动到新位置。服务器返回此响应(对 GET 或 HEAD 请求的响应)时,会自动将请求者转到新位置。
③重定向完成,客户以https请求资源。此时容器发现用户还未认证,会弹出登陆界面。
④浏览器弹出登录界面,用户进行登陆,再次请求该资源。
⑤检查,如果有权访问则返回资源。


  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值