一键难忘520

这个屌丝很懒，什么也没留下！

热门标签

web安全_security-constraint配置

作者：一键难忘520 | 2024-08-10 00:35:23

踩

security-constraint配置

一、打开认证：

<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>

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请求资源。此时容器发现用户还未认证，会弹出登陆界面。

④浏览器弹出登录界面，用户进行登陆，再次请求该资源。

⑤检查，如果有权访问则返回资源。

声明：本文内容由网友自发贡献，不代表【wpsshop博客】立场，版权归原作者所有，本站不承担相应法律责任。如您发现有侵权的内容，请联系我们。转载请注明出处：https://www.wpsshop.cn/w/一键难忘520/article/detail/955899