赞
踩
客户端向 Spring Cloud Gateway 发出请求。如果Gateway处理程序映射确定一个请求与路由相匹配,它将被发送到Gateway Web处理程序。这个处理程序通过一个特定于该请求的过滤器链来运行该请求。过滤器被虚线分割的原因是,过滤器可以在代理请求发送之前和之后运行逻辑。所有的 "pre"
(前)过滤器逻辑都被执行。然后发出代理请求。在代理请求发出后,"post"
(后)过滤器逻辑被运行
路由转发:这是网关最主要的功能,通过配置统一将请求转发至相应的服务,否则客户端需多次请求不同的微服务,增加客户端代码或配置编写的复杂性,目前官网给出的配置条件有:After(某个时间后的请求转发至该服务)、Before(某个时间前的请求转发至该服务)、Between(某个时间范围的请求转发至该服务)、Cookie(匹配到对应的Cookie值)、Header(匹配到对应的Header值)、Host(匹配到对应的域名)、Method(匹配到对应的get/post请求)、Path(匹配到对应的url)、Query(匹配到对应的参数)、RemoteAddr(匹配到对应的RemoteAddr)、Weight(设定分流的权重)原文链接:https://blog.csdn.net/wen5026/article/details/122333171
熔断:可以通过配置FallbackHeaders GatewayFilter Factory进行熔断
限流:可以通过配置RequestRateLimiter GatewayFilter Factory对请求进行限流
鉴权:网关层可以进行统一鉴权,实现Global Filters完成全局的鉴权,实现Gateway Filter可完成单个路由的鉴权
@Component @Slf4j public class GatewayAuthFilter implements GlobalFilter, Ordered { //白名单 private static List<String> whitelist = null; static { //加载白名单 try ( InputStream resourceAsStream = GatewayAuthFilter.class.getResourceAsStream("/security-whitelist.properties"); ) { Properties properties = new Properties(); properties.load(resourceAsStream); Set<String> strings = properties.stringPropertyNames(); whitelist= new ArrayList<>(strings); } catch (Exception e) { log.error("加载/security-whitelist.properties出错:{}",e.getMessage()); e.printStackTrace(); } } @Autowired private TokenStore tokenStore; @Override public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) { String requestUrl = exchange.getRequest().getPath().value(); AntPathMatcher pathMatcher = new AntPathMatcher(); //白名单放行 for (String url : whitelist) { if (pathMatcher.match(url, requestUrl)) { return chain.filter(exchange); } } //检查token是否存在 String token = getToken(exchange); if (StringUtils.isBlank(token)) { return buildReturnMono("没有认证",exchange); } //判断是否是有效的token OAuth2AccessToken oAuth2AccessToken; try { oAuth2AccessToken = tokenStore.readAccessToken(token); boolean expired = oAuth2AccessToken.isExpired(); if (expired) { return buildReturnMono("认证令牌已过期",exchange); } return chain.filter(exchange); } catch (InvalidTokenException e) { log.info("认证令牌无效: {}", token); return buildReturnMono("认证令牌无效",exchange); } }
网关常用的还有Zuul、基于Nginx的OpenResty
相同点:都是可以实现对api接口的拦截,负载均衡、反向代理、请求过滤等,可以实现和网关一样的效果。
不同点:
ServerWebExchange
。这让你可以在HTTP请求中的任何内容上进行匹配,比如header或查询参数。GatewayFilter
的实例,已经用特定工厂构建。在这里,你可以在发送下游请求之前或之后修改请求和响应。Spring Security是一个Java框架,用于保护应用程序的安全性。它提供了一套全面的安全解决方案,包括身份验证、授权、防止攻击等功能。Spring Security基于过滤器链的概念,可以轻松地集成到任何基于Spring的应用程序中。
SecurityContextHolder
Spring Security 的认证模型的核心是 SecurityContextHolder
。它包含了SecurityContext。
SecurityContext context = SecurityContextHolder.createEmptyContext();
Authentication authentication = new TestingAuthenticationToken("username", "password", "ROLE_USER");
context.setAuthentication(authentication);
SecurityContextHolder.setContext(context);
AbstractAuthenticationProcessingFilter
Authentication
讨论了所有 Authentication
实现如何存储 GrantedAuthority
对象的列表。这些对象代表已经授予委托人(principal)的权限。GrantedAuthority
对象由 AuthenticationManager
插入到 Authentication
对象中,随后由 AccessDecisionManager
实例在做出授权决定时读取。
GrantedAuthority
接口只有一个方法。
String getAuthority();
主要提供了对CSRF、HTTP Header、HTTP的保护
学成在线:
JSON Web Token(JWT)是一种使用JSON格式传递数据的网络令牌技术,它是一个开放的行业标准(RFC 7519),用于在通信双方传递json对象,传递的信息经过数字签名可以被验证和信任,它可以使用HMAC算法或使用RSA的公钥/私钥对来签名,防止内容篡改。
头信息指定了该JWT使用的签名算法:
header = '{"alg":"HS256","typ":"JWT"}'
消息体包含了JWT的意图:
payload = '{"loggedInAs":"admin","iat":1422779638}'//iat表示令牌生成的时间
未签名的令牌由base64url
编码的头信息和消息体拼接而成(使用"."分隔),签名则通过私有的key计算而成:
key = 'secretkey'
unsignedToken = encodeBase64(header) + '.' + encodeBase64(payload)
signature = HMAC-SHA256(key, unsignedToken)
最后在未签名的令牌尾部拼接上base64url
编码的签名(同样使用"."分隔)就是JWT了:
token = encodeBase64(header) + '.' + encodeBase64(payload) + '.' + encodeBase64(signature)
# token看起来像这样: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJsb2dnZWRJbkFzIjoiYWRtaW4iLCJpYXQiOjE0MjI3Nzk2Mzh9.gzSraSYS8EXBxLN_oWnFSRgCzcmJmMjLiuyu5CSpyHI
JWT的优点:
JWT的缺点:
SpringSecurity:
RBAC允许您通过分配一组权限来创建和实施高级访问。权限基于特定用户类别执行其职责所需的访问级别。换句话说,公司中的不同人员可以完全基于其工作职能和职责等因素拥有完全不同的访问权限级别和类型。
RBAC最大的优点之一是它提供了一种系统化的方法,用于定义和维护角色,使您能够仅根据用户需要一致地授予访问权限,从而降低数据泄露或数据丢失的风险。
但RBAC还有很多其他好处,包括:
需要了解组织结构知识
没有一种一刀切的方法来定义角色。在决定如何对角色进行分类以及如何管理这些角色的访问权限时,组织必须跨部门协调。这需要清楚地了解组织的理想结构以及支持它的技术基础设施。
在大型或成长中的组织中,如果IT或安全经理需要在没有人力资源或执行决策者帮助的情况下定义角色,这可能是一项艰巨的任务,会变得更加困难。这种简化实施的常见尝试实际上使问题变得更糟,导致与公司更大的目标不一致。
需要深思熟虑的实施
分配角色可能是一项挑战。可能会出现很多问题,答案并不总是清晰的。例如:安全团队是否需要访问他们试图保护的数据,包含哪些访问权限(创建/读取/更新/删除)?是否应为用户分配部门之外的角色,以确保临时访问特权文件?
缺乏灵活性
RBAC以过于死板著称,这也难怪。组织成长,团队扩张,访问需求发生变化。在RBAC项目开始时定义的角色可能不再符合公司目标。
结果如何?人员的角色和权限级别可能不一致。例如,一个人可能被赋予过多的角色权限、分配过多的角色,或者两者兼而有之。虽然这些努力可能会起到快速修复的作用,但它们也会造成安全漏洞和法规遵从性挑战,从而打消了您最初实施RBAC的全部原因。
导致角色爆炸
一些团队试图通过定义越来越细粒度的角色、在出现新需求时创建临时角色,或将太多的角色分配给单个用户来回避上述问题。虽然这可能会在短期内缓解摩擦,但也会让RBAC变得混乱,难以管理。
这个问题通常被称为角色爆炸,是RBAC最常见的反对意见之一。当现实世界中的角色和访问需求与您的政策文件中概述的角色和访问需求不同时,甚至在很小的程度上也会出现这种情况。而作为临时解决方案创建的角色有时管理员可能会忘记或甚至故意选择保留这些角色,即使为其创建这些角色的人员离开或更换组织内的工作。结果是:特权蔓延和混乱。
AC的全部原因。
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。