淄博网站建设培训学校为什么打不开中国建设银行网站

当前位置： 首页 > news >正文

淄博网站建设培训学校,为什么打不开中国建设银行网站,中国中国建设银行网站首页,新建网站怎么想谷歌和百度提交第一章 初识 Spring Security 1、权限管理 权限管理 基本上涉及到用户参与的系统都要进行权限管理#xff0c;权限管理属于系统安全的范畴#xff0c;权限管理实现了对用户访问系统的控制#xff0c;按照安全规则或者安全策略控制用户可以访问而且只能访问自己被授权的资…第一章 初识 Spring Security 1、权限管理 权限管理 基本上涉及到用户参与的系统都要进行权限管理权限管理属于系统安全的范畴权限管理实现了对用户访问系统的控制按照安全规则或者安全策略控制用户可以访问而且只能访问自己被授权的资源。权限管理包括用户身份认证和授权两部分简称认证授权。对于访问控制的资源用户首先需要经过身份认证认证通过后用户具有该资源的访问权限方可访问。 认证 身份认证就是判断一个用户是否为合法用户的处理过程。最常用的简单身份认证方式是系统通过核对用户输入的用户名和口令看其是否与系统中存储的该用户的用户名和口令一致来判断用户身份是否正确。对于采用指纹等系统则出示指纹对于硬件Key等刷卡系统则需要刷卡。 授权 授权即访问控制控制谁能访问哪些资源。用户进行身份认证后需要分配权限方可访问系统的资源对于某些资源如果没有权限那么该用户是无法访问的。 行业解决方案 和其他领域不同在 Java 企业级开发中安全管理框架非常少目前比较常见的就是 Shiro Shiro 本身是一个老牌的安全管理框架有着众多的优点例如轻量、简单、易于集成、可以在 JavaSE 环境中使用等。不过在微服务时代Shiro 就显得力不从心了它在微服务面前和扩展方面无法充分展示自己的优势。 开发者自定义 也有很多公司选择自定义权限即自己开发权限管理。但是一个系统的安全不仅仅是登录和权限控制这么简单我们还要考虑各种各样可能存在的网络政击以及防御策略从这个角度来说开发者自己实现安全管理也并非是一件容易的事情只有大公司才有足够的人力物力去支持这件事情。 Spring Security Spring Security作为 Spring 家族的一员在和 Spring 家族的其他成员如 Spring Boot、Spring Clond 等进行整合时具有其他框架无可比拟的优势同时对 OAuth2 有着良好的支持再加上 Spring Cloud 对 Spring Security 的不断加持如推出 Spring Cloud Security )让 Spring Securiy 不知不觉中成为微服务项目的首选安全管理方案。 简介 官方定义 https://spring.io/projects/spring-security Spring Security 是一个功能强大、可高度定制的身份验证和访问控制的框架。它是保护基于 Spring 应用程序的事实标准。 Spring Security 是一个面向 Java 应用程序提供身份验证和安全性的框架。与所有 Spring 项目一样Spring Security 的真正威力在于它可以轻松地扩展以满足定制需求。 历史 Spring Security 最早叫 Acegi Security 这个名称并不是说它和 Spring 就没有关系它依然是为 Spring 框架提供安全支持的。Acegi Security 基于 Spring可以帮助我们为项目建立丰富的角色与权限管理系统。Acegi Security 虽然好用但是最为让人诟病的则是它臃肿繁琐的配置这一问题最终也遗传给了 Spring Security。 Acegi Security 最终被并入 Spring Security 项目中并于 2008 年4月发布了改名后的第一个版本 Spring Security 2.0.0到目前为止Spring Security 的最新版本己经到了 5.6.1。和 Shiro 相比Spring Security 重量级并且配置繁琐直至今天依然有人以此为理由而拒绝了解 Spring Security。其实自从 Spring Boot 推出后就彻底颠覆了传统了 JavaEE 开发自动化配置让许多事情变得非常容易包括 Spring Security 的配置。在一个 Spring Boot 项目中我们甚至只需要引入一个依赖不需要任何额外配置项目中的所有接口就会被自动保护起来了。在 Spring Cloud中很多涉及安全管理的问题也是一个 Spring Security 依赖两行配置就能搞定在和 Spring 家族的产品一起使用时Spring Security 的优势就非常明显了。 因此在微服务时代我们不需要纠结要不要学习 Spring Security我们要考虑的是如何快速掌握 Spring Security 并且能够使用 Spring Security 实现我们微服务的安全管理。 整体架构 在 Spring Security 的架构设计中认证 和 授权 是分开的无论使用什么样的认证方式。都不会影响授权这是两个独立的存在这种独立带来的好处之一就是可以非常方便地整合一些外部的解决方案。 认证 1、AuthenticationManager 在 Spring Security 中认证是由 AuthenticationManager 接口来负责的接口定义为 public interface AuthenticationManager { Authentication authenticate(Authentication authentication) throws AuthenticationException; }返回 Authentication 表示认证成功返回 AuthenticationException 异常表示认证失败。 AuthenticationManager 主要实现类为 ProviderManager在 ProviderManager 中管理了众多 AuthenticationProvider 实例。在一次完整的认证流程中Spring Security 允许存在多个 AuthenticationProvider 用来实现多种认证方式这些 AuthenticationProvider 都是由 ProviderManager 进行统一管理的。 2、Authentication 认证以及认证成功的信息主要是由 Authentication 的实现类进行保存的其接口定义为 public interface Authentication extends Principal, Serializable {Collection? extends GrantedAuthority getAuthorities();Object getCredentials();Object getDetails();Object getPrincipal();boolean isAuthenticated();void setAuthenticated(boolean isAuthenticated) throws IllegalArgumentException; }getAuthorities获取用户权限信息getCredentials获取用户凭证信息一般指密码getDetails获取用户详细信息getPrincipal获取用户身份信息用户名、用户对象等isAuthenticated用户是否认证成功 3、SecurityContextHolder SecurityContextHolder 用来获取登录之后的用户信息。Spring Security 会将登录用户数据保存在 Session 中。但是为了使用方便Spring Security 在此基础上还做了一些改进其中最主要的一个变化就是线程绑定。当用户登录成功之后Spring Security 会将登录成功的用户信息保存到 SecurityContextHolder 中。 SecurityContextHolder 中的数据保存默认是通过 ThreadLocal 来实现的使用 ThreadLocal 创建的变量只能被当前线程访问不能被其他线程访问和修改也就是将用户数据和请求线程绑定在一起。当登录请求处理完毕后Spring Security 会将 SecurityContextHolder 中的数据拿出来保存到 Session 中同时将 SecurityContexHolder 中的数据清空。以后每当有请求到来时Spring Security 就会先从 Session 中取出用户登录数据保存到 SecurityContextHolder 中方便在该请求的后续处理过程中使用同时在请求结束时将 SecurityContextHolder 中的数据拿出来保存到 Session 中然后将 Security SecurityContextHolder 中的数据清空。这一策略非常方便用户在 Controller、Service 层以及任何代码中获取当前登录用户数据。 授权 当完成认证后接下来就是授权了。在 Spring Security 的授权体系中有两个关键接口 1、AccessDecisionManager AccessDecisionManager访问决策管理器用来决定此次访问是否被允许。 2、AccessDecisionVoter AccessDecisionVoter访问决定投票器投票器会检查用户是否具备应有的角色进而投出赞成、反对或者弃权票。 AccessDecisionVoter 和 AccessDecisionManager 都有众多的实现类在 AccessDecisionManager 中会挨个遍历 AccessDecisionVoter进而决定是否允许用户访问因而 AccessDecisionVoter 和 AccessDecisionManager 两者的关系类似于 AuthenticationProvider 和 ProviderManager 的关系。 3、ConfigAttribute ConfigAttribute用来保存授权时的角色信息。 在 Spring Security 中用户请求一个资源通常是一个接口或者是一个 Java 方法需要的角色会被封装成一个 ConfigAttribute 对象在 ConfigAttribute 中只有一个 getAttribute 方法该方法返回一个 String 字符串就是角色的名称。一般来说角色名称都带有一个 ROLE_ 前缀投票器 AccessDecisionVoter 所做的事情其实就是比较用户所具备的角色和请求某个资源所需要的 ConfigAttribute 之间的关系。 2、环境搭建 Spring BootSpring Security 认证判断用户是否是系统合法用户的过程授权判断系统内的用户可以访问或具有访问哪些资源的权限的过程
整合 Spring Security 1、创建 Spring Boot 应用 2、引入 Spring Security 相关依赖 !–引入spring security依赖– dependencygroupIdorg.springframework.boot/groupIdartifactIdspring-boot-starter-security/artifactId /dependency3、创建 Controller RestController public class HelloController {RequestMapping(/hello)public String hello() {System.out.println(hello security);return hello spring security;}}4、启动项目 启动完成后在控制台会生成一个密码访问 /hello 发现直接跳转到登录页面 5、登录系统

• 默认用户名为: user
• 默认密码为: 控制台打印的uuid这就是 Spring Security 的强大之处只需要引入一个依赖所有的接口就会被自动保护起来 思考? 为什么引入 Spring Security 之后没有任何配置所有请求就要认证呢?在项目中明明没有登录界面登录界面怎么来的呢为什么使用 user 和 控制台密码 就能完成登陆登录时验证数据源存在哪里呢 实现原理 https://docs.spring.io/spring-security/site/docs/5.5.4/reference/html5/#servlet-architecture 虽然开发者只需要引入一个依赖就可以让 Spring Security 对应用进行保护。那么 Spring Security 又是如何做到的呢 在 Spring Security 中 认证、授权 等功能都是基于过滤器完成的。 需要注意的是默认过滤器并不是直接放在 Web 项目的原生过滤器链中而是通过一个 FlterChainProxy 来统一管理。Spring Security 中的过滤器链通过 FilterChainProxy 嵌入到 Web 项目的原生过滤器链中。FilterChainProxy 作为一个顶层的管理者将统一管理 Security Filter。FilterChainProxy 本身是通过 Spring 框架提供的 DelegatingFilterProxy 整合到原生的过滤器链中。 Security Filters 那么在 Spring Security 中默认给我们提供了哪些过滤器呢 ? 哪些过滤器会被加载呢 ? 以下是 Spring Security Filter 排序的完整列表 过滤器过滤器作用默认是否加载ChannelProcessingFilter过滤请求协议 HTTP 、HTTPSNOWebAsyncManagerIntegrationFilter将 WebAsyncManger 与 SpringSecurity 上下文进行集成YESSecurityContextPersistenceFilter在处理请求之前,将安全信息加载到 SecurityContextHolder 中YESHeaderWriterFilter处理头信息加入到响应中YESCorsFilter处理跨域问题NOCsrfFilter处理 CSRF 攻击YESLogoutFilter处理注销登录YESOAuth2AuthorizationRequestRedirectFilter处理 OAuth2 认证重定向NOSaml2WebSsoAuthenticationRequestFilter处理 SAML 认证NOX509AuthenticationFilter处理 X509 认证NOAbstractPreAuthenticatedProcessingFilter处理预认证问题NOCasAuthenticationFilter处理 CAS 单点登录NOOAuth2LoginAuthenticationFilter处理 OAuth2 认证NOSaml2WebSsoAuthenticationFilter处理 SAML 认证NOUsernamePasswordAuthenticationFilter处理表单登录YESOpenIDAuthenticationFilter处理 OpenID 认证NODefaultLoginPageGeneratingFilter配置默认登录页面YESDefaultLogoutPageGeneratingFilter配置默认注销页面YESConcurrentSessionFilter处理 Session 有效期NODigestAuthenticationFilter处理 HTTP 摘要认证NOBearerTokenAuthenticationFilter处理 OAuth2 认证的 Access TokenNOBasicAuthenticationFilter处理 HttpBasic 登录YESRequestCacheAwareFilter处理请求缓存YESSecurityContextHolderAwareRequestFilter包装原始请求YESJaasApiIntegrationFilter处理 JAAS 认证NORememberMeAuthenticationFilter处理 RememberMe 登录NOAnonymousAuthenticationFilter配置匿名认证YESOAuth2AuthorizationCodeGrantFilter处理OAuth2认证中授权码NOSessionManagementFilter处理 session 并发问题YESExceptionTranslationFilter处理认证/授权中的异常YESFilterSecurityInterceptor处理授权相关YESSwitchUserFilter处理账户切换NO 可以看出Spring Security 提供了 30 多个过滤器。默认情况下 Spring Boot 在对 Spring Security 进入自动化配置时会创建一个名为 SpringSecurityFilerChain 的过滤器并注入到 Spring 容器中这个过滤器将负责所有的安全管理包括用户认证、授权、重定向到登录页面等。具体可以参考 WebSecurityConfiguration 的源码 SpringBootWebSecurityConfiguration 这个类是 Spring Boot 的自动配置类通过这个源码得知默认情况下对所有请求进行权限控制 Configuration(proxyBeanMethods false) // 什么时候使用默认的Spring Security呢点击这个类看看 ConditionalOnDefaultWebSecurity ConditionalOnWebApplication(type Type.SERVLET) class SpringBootWebSecurityConfiguration {BeanOrder(SecurityProperties.BASIC_AUTH_ORDER)// HttpSecurity这里先当做Http请求SecurityFilterChain defaultSecurityFilterChain(HttpSecurity http) throws Exception {// 默认对所有的Http请求都需要认证之后才能进行访问http.authorizeRequests().anyRequest().authenticated().and().formLogin().and().httpBasic();return http.build();}}这也就是为什么在引入 Spring Security 中没有任何配置得情况下请求会被拦截的原因 通过上面对自动配置的分析我们也能看出默认生效的条件为 条件一ClassPath 中存在 SecurityFilterChain.class、HttpSecurity.class条件二在 Spring 容器中没有找到 WebSecurityConfigurerAdapter.class、SecurityFilterChain.class 对应的 Bean 对象 修改配置用 WebSecurityConfigurerAdapter扩展 Filter用 SecurityFilterChain
  默认情况下这两个条件都是满足的。WebSecurityConfigurerAdapter 这个类极其重要Spring Security 的核心配置都在这个类中 如果要对 Spring Security 进行自定义配置就要自定义这个类实例通过覆盖类中的方法以达到修改默认配置的目的。 流程分析 1、请求 /hello 接口在引入 Spring Security 之后会先经过一些过滤器。 2、在请求到达 FilterSecurityInterceptor时发现请求并未认证。请求拦截下来并抛出 AccessDeniedException 异常。 3、抛出 AccessDeniedException 的异常会被 ExceptionTranslationFilter 捕获这个 Filter 中会调用 LoginUrlAuthenticationEntryPoint#commence 方法给客户端返回 302要求客户端进行重定向到 /login 页面。 4、客户端发送 /login 请求。 5、/login 请求会再次被拦截器中的 DefaultLoginPageGeneratingFilter 拦截到并在拦截器中返回生成的登录页面。 通过这种方式Spring Security 默认过滤器中生成了登录页面并返回 默认用户生成 1、查看 SpringBootWebSecurityConfiguration#defaultSecurityFilterChain 方法进行表单登录 2、处理登录为 FormLoginConfigurer 类在里面调用了 UsernamePasswordAuthenticationFilter 这个类实例 3、查看类中的 UsernamePasswordAuthenticationFilter#attempAuthentication 方法得知实际调用的是 AuthenticationManager 类中的 authenticate 方法 4、调用 ProviderManager 类中的 authenticate 方法 5、调用了 ProviderManager 的实现类 AbstractUserDetailsAuthenticationProvider 类中的 authenticate 方法 6、最终调用实现类 DaoAuthenticationProvider 中的方法作比较 看到这里就能发现默认是基于 InMemoryUserDetailsManager 这个类实现的也就是基于内存的实现 UserDetailService 通过源码分析也能得知 UserDetailService 是顶层父接口接口中的 loadUserByUserName 方法是用来在认证时进行用户名认证的默认是基于内存实现的如果想要修改成基于数据库实现我们只需要自定义 UserDetailService 实现类最终返回 UserDetails 实例即可。 UserDetailsServiceAutoConfiguration 这个源码非常多这里梳理了关键部分 Configuration(proxyBeanMethods false) ConditionalOnClass(AuthenticationManager.class) ConditionalOnBean(ObjectPostProcessor.class) ConditionalOnMissingBean(value { AuthenticationManager.class, AuthenticationProvider.class, UserDetailsService.class,AuthenticationManagerResolver.class },type { org.springframework.security.oauth2.jwt.JwtDecoder,org.springframework.security.oauth2.server.resource.introspection.OpaqueTokenIntrospector,org.springframework.security.oauth2.client.registration.ClientRegistrationRepository }) public class UserDetailsServiceAutoConfiguration {//….BeanLazypublic InMemoryUserDetailsManager inMemoryUserDetailsManager(SecurityProperties properties,ObjectProviderPasswordEncoder passwordEncoder) {SecurityProperties.User user properties.getUser();ListString roles user.getRoles();return new InMemoryUserDetailsManager(User.withUsername(user.getName()).password(getOrDeducePassword(user, passwordEncoder.getIfAvailable())).roles(StringUtils.toStringArray(roles)).build());}//… }条件一从自动配置源码中得知当 ClassPath 下存在 AuthenticationManager 类 条件二当前项目中系统没有提供 AuthenticationManager.class、 AuthenticationProvider.class、UserDetailsService.class、 AuthenticationManagerResolver.class 对应的 Bean 对象 这两个条件默认情况下都会满足此时 Spring Security 会提供一个 InMemoryUserDetailManager 实例 ConfigurationProperties(prefix spring.security) public class SecurityProperties {private final User user new User();public User getUser() {return this.user;}//….public static class User {private String name user;private String password UUID.randomUUID().toString();private ListString roles new ArrayList();private boolean passwordGenerated true;//get set …}}这就是默认生成 user 以及 uuid 密码的过程另外看明白源码之后就知道只要在配置文件中加入以下配置就可以对内存中的用户名和密码进行覆盖。 总结 AuthenticationManager、ProviderManger、以及 AuthenticationProvider 的关系 WebSecurityConfigurerAdapter扩展 Spring Security 的所有默认配置 UserDetailService用来修改默认认证的数据源信息