【问题标题】:How exactly works this Spring Security example?这个 Spring Security 示例到底是如何工作的?
【发布时间】:2016-01-21 17:55:46
【问题描述】:

我是 Spring Security 的新手,我对教程中找到的配置有一些疑问。

这是spring-security.xml文件,用于将Spring Security配置到项目中:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:security="http://www.springframework.org/schema/security"
    xsi:schemaLocation="http://www.springframework.org/schema/security http://www.springframework.org/schema/security/spring-security-4.0.xsd
        http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd">

    <security:http>
        <security:intercept-url pattern="/springLogin" access="permitAll"/>
        <security:intercept-url pattern="/doSpringLogin" access="permitAll"/>
        <security:intercept-url pattern="/myprofile" access="hasRole('ROLE_USER')"/>
        <security:intercept-url pattern="/springHome" access="hasRole('ROLE_USER')"/> 
        <security:intercept-url pattern="/products" access="hasRole('ROLE_USER')"/> 
        <security:intercept-url pattern="/springLogout" access="permitAll"/>
        <security:intercept-url pattern="/springLogin?error=true" access="permitAll"/>
        <security:form-login login-page="/springLogin" login-processing-url="/doSpringLogin"
        default-target-url="/springHome" authentication-failure-url="/springLogin?error=true"
        username-parameter="username" password-parameter="password"
        />
        <security:csrf disabled="true"/>
        <security:logout logout-url="/springLogout" logout-success-url="/springLogin"/>
    </security:http>

    <bean id="userDetailsServiceImpl" class="com.demo.security.UserDetailsServiceImpl"></bean>

    <bean id="authenticationProvider" class="org.springframework.security.authentication.dao.DaoAuthenticationProvider">
        <property name="userDetailsService" ref="userDetailsServiceImpl"></property>
    </bean>

    <bean id="authenticationManager" class="org.springframework.security.authentication.ProviderManager">
        <constructor-arg name="providers">
            <list>
                <ref bean="authenticationProvider"/>
            </list>
        </constructor-arg>
    </bean>

    <security:authentication-manager>
        <security:authentication-provider user-service-ref="userDetailsServiceImpl">
            <security:password-encoder hash="plaintext"></security:password-encoder>
        </security:authentication-provider>
    </security:authentication-manager>

</beans>

我把它分成了一些部分。第一个是标签内容。

它包含以下内容:

<security:intercept-url pattern="/springLogin" access="permitAll"/>

我认为这意味着与 /springLogin 资源相关的页面可供所有人访问,同时

<security:intercept-url pattern="/myprofile" access="hasRole('ROLE_USER')"/>

表示与 /myprofile 资源相关的资源只能由设置了 ROLE_USER 角色的登录用户(主体)访问。

这个推理正确吗?

那么在之前的配置文件中有:

1) authenticationManager bean 的声明:

<bean id="authenticationManager" class="org.springframework.security.authentication.ProviderManager">
    <constructor-arg name="providers">
        <list>
            <ref bean="authenticationProvider"/>
        </list>
    </constructor-arg>
</bean>

我认为 Spring 使用它来使用 Principal 对象(例如 Web 应用程序的所有用户)和 填充 SecurityContext授权(具体的委托人可以做什么)。

这个推理正确吗?

此对象将一个 autentication provider bean 列表作为构造函数 arg,这些 bean 必须提供 Principal 信息(例如,与特定 Principal 关联的角色)

在这种情况下,提供了一个 DaoAuthenticationProvider 类的实现,该类采用具有 name="userDetailsS​​ervice" 作为属性的 bean,这个:

<bean id="userDetailsServiceImpl" class="com.demo.security.UserDetailsServiceImpl"></bean>

那是 UserDetailsS​​erviceImpl 类的一个实例,这个:

public class UserDetailsServiceImpl implements UserDetailsService {

    @Override
    public UserDetails loadUserByUsername(String username)
            throws UsernameNotFoundException {
        System.out.println(username);
        User user = RegisteryDAO.getUserDAO().getUserByUsername(username);

        if(user == null){
            return null;
        }

        List<GrantedAuthority> authorities = new ArrayList<GrantedAuthority>();
        authorities.add(new SimpleGrantedAuthority(user.getRole()));

        UserDetails userDetails = new org.springframework.security.core.userdetails.
                User(user.getUsername(), user.getPassword(), true, true, true, true, authorities);


        return userDetails;
    }

}

那么到底发生了什么?

使用调试器在我看来,当用户尝试访问特定页面时,此 loadUserByUsername() 返回与已登录用户相关的 UserDetails 对象,其中包含List 表示与特定登录用户关联的角色(例如之前的 ROLE_USER

那我认为Spring自动使用了

<security:intercept-url pattern="/myprofile" access="hasRole('ROLE_USER')"/>

检查用户是否已将 propper 角色设置到上一个 List 列表中。

如果它已经将请求转发到处理此 Http 请求的控制器方法,否则避免此 HttpRequest 到达此控制器方法并显示一个说用户无法访问此资源的页面。

【问题讨论】:

    标签: java spring spring-mvc jakarta-ee spring-security


    【解决方案1】:

    这里解释了您所询问的一些概念和问题。


    AuthenticationManager

    AuthenticationManager 是负责处理Authentication 请求的组件。身份验证请求可能是UsernamePasswordAuthenticationToken 的实例,用于用户名/密码登录。

    其他实现请查看Authentication JavaDoc

    AuthenticationManager 也有AuthenticationProvider 实现的集合。这些组件能够处理特定的Authentication 类型,AuthenticationManager 遍历它们,试图找到一个能够处理传递给它的Authentication 的组件。如果找到,它会调用它并提供Authentication 对象,如果成功则返回完全填充的Authentication 对象(否则会抛出AuthenticationException)。


    AuthenticationProvider

    如上所述,AuthenticationProvider 处理特定类型的Authentication 请求。例如,DaoAuthenticationProvider 在被AuthenticationManager 调用时将执行以下步骤:

    • UsernamePasswordAuthenticationToken 传递给它
    • 使用提供给它的UserDetailsService 服务实现(在您的情况下是UserDetailServiceImpl)通过用户名查找用户
    • 使用PasswordEncoderSaltSource(如果指定)针对用户检查身份验证令牌中提供的密码。
    • 如果身份验证成功,则返回填充的身份验证对象(本例中为UsernamePasswordAuthenticationToken),其中包含主体、凭据并标记为authenticated
    • 如果认证失败,会抛出AuthenticationException

    您正在使用的DaoAuthenticationProvider 能够处理UsernamePasswordAuthenticationToken 请求。所以通常是表单登录,等等。您可以通过查看其supports() 方法实现来了解哪些类型的身份验证提供程序支持,在DaoAuthenticationProvider 的情况下看起来像这样:

    public boolean supports(Class<?> authentication) {
        return (UsernamePasswordAuthenticationToken.class.isAssignableFrom(authentication));
    }
    

    Spring 安全过滤链

    现在让我们看看Spring Security documentation定义的安全过滤器链:

    过滤器在链中定义的顺序非常重要。 无论您实际使用哪种过滤器,订单都应该 如下:

    1. ChannelProcessingFilter,因为它可能需要重定向到不同的协议

    2. SecurityContextPersistenceFilter,因此可以在 Web 请求开始时在 SecurityContextHolder 中设置 SecurityContext,并且 对 SecurityContext 的任何更改都可以复制到 HttpSession 当网络请求结束时(准备好与下一个网络请求一起使用)

    3. ConcurrentSessionFilter,因为它使用 SecurityContextHolder 功能但需要更新 SessionRegistry 以反映 校长的持续请求

    4. 身份验证处理机制 - UsernamePasswordAuthenticationFilterCasAuthenticationFilterBasicAuthenticationFilter 等 - 这样SecurityContextHolder 就可以 修改为包含有效的身份验证请求令牌

    5. The SecurityContextHolderAwareRequestFilter,如果您使用它来安装 Spring Security 感知 HttpServletRequestWrapper 到您的 servlet 容器

    6. RememberMeAuthenticationFilter,这样如果没有更早的认证处理机制更新SecurityContextHolder, 并且该请求提供了一个 cookie,该 cookie 使 remember-me 服务能够 发生时,将放置一个合适的记忆身份验证对象 那里

    7. AnonymousAuthenticationFilter,这样如果没有更早的认证处理机制更新SecurityContextHolder, 将放置一个匿名身份验证对象

    8. ExceptionTranslationFilter,捕获任何 Spring Security 异常,以便可以返回 HTTP 错误响应或 可以启动适当的 AuthenticationEntryPoint

    9. FilterSecurityInterceptor,用于保护 Web URI 并在访问被拒绝时引发异常

    当用户提交登录表单时,AuthenticationManager 在过滤器链的第 4 步被调用。在表单登录的情况下,它将由UsernamePasswordAuthenticationFilter 处理,它调用AuthenticationManager 来处理身份验证:

    public Authentication attemptAuthentication(HttpServletRequest request,
            HttpServletResponse response) throws AuthenticationException {
        // ...
        return this.getAuthenticationManager().authenticate(authRequest);
    }
    

    使用调试器在我看来,当用户尝试访问特定页面时,此 loadUserByUsername() 返回 UserDetails

    实际上loadUserByUsername() 是在用户进行身份验证时调用的,例如在提交登录表单之后。如果用户已经通过身份验证,则不会调用它。

    我认为这意味着每个人都可以访问与/springLogin 资源相关的页面:

    <security:intercept-url pattern="/springLogin" access="permitAll" />
    

    然后我认为Spring会自动使用以下来检查用户是否具有正确的角色:

    <security:intercept-url pattern="/myprofile" access="hasRole('ROLE_USER')" />
    

    正确。这个过程由FilterSecurityInterceptor 处理,它扩展了AbstractSecurityInterceptor - 处理授权的核心Spring Security 组件。如果用户未通过身份验证或不具有所需角色,则会引发异常并由ExceptionTranslationFilter 处理。此过滤器处理安全异常。例如,在身份验证失败的情况下,它将用户重定向到身份验证入口点,例如登录页面。


    reference documentation 很好地描述了 Spring Security 的内部架构。建议去看看。

    【讨论】:

      猜你喜欢
      • 2016-03-18
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2017-06-03
      • 1970-01-01
      • 2018-03-03
      • 1970-01-01
      • 2014-07-20
      相关资源
      最近更新 更多