做路牌的网站,花钱做推广广告哪个网站好,2345浏览器免费版,为了推出企业网站建设一、同时支持JWT和Opaque Token
在某些情况下#xff0c;你可能需要访问两种令牌。例如#xff0c;你可能支持一个以上的租户#xff0c;其中一个租户发出JWT#xff0c;另一个发出 opaque token。
如果这个决定必须在请求时做出#xff0c;那么你可以使用 Authenticati…一、同时支持JWT和Opaque Token
在某些情况下你可能需要访问两种令牌。例如你可能支持一个以上的租户其中一个租户发出JWT另一个发出 opaque token。
如果这个决定必须在请求时做出那么你可以使用 AuthenticationManagerResolver 来实现它就像这样。 Java
Bean
AuthenticationManagerResolverHttpServletRequest tokenAuthenticationManagerResolver(JwtDecoder jwtDecoder, OpaqueTokenIntrospector opaqueTokenIntrospector) {AuthenticationManager jwt new ProviderManager(new JwtAuthenticationProvider(jwtDecoder));AuthenticationManager opaqueToken new ProviderManager(new OpaqueTokenAuthenticationProvider(opaqueTokenIntrospector));return (request) - useJwt(request) ? jwt : opaqueToken;
}
useJwt(HttpServletRequest) 的实现很可能取决于自定义的请求如路径。
然后在DSL中指定这个 AuthenticationManagerResolver。
Authentication Manager Resolver Java
http.authorizeHttpRequests(authorize - authorize.anyRequest().authenticated()).oauth2ResourceServer(oauth2 - oauth2.authenticationManagerResolver(this.tokenAuthenticationManagerResolver)); 二、多租户
当有多种验证 bearer token 的策略时一个资源服务器被认为是多租户的其关键是一些租户标识符。
例如你的资源服务器可能接受来自两个不同授权服务器的 bearer token。或者你的授权服务器可以代表多个发行者。
在每一种情况下都有两件事需要做以及与你选择如何做有关的权衡。 解析租户。 传递租户。
1、通过 Claim 解析租户
区分租户的一个方法是通过 issuer claim。由于 issuer claim 伴随着签名的JWTs这可以通过 JwtIssuerAuthenticationManagerResolver 来完成像这样。
Multi-tenancy Tenant by JWT Claim Java
JwtIssuerAuthenticationManagerResolver authenticationManagerResolver new JwtIssuerAuthenticationManagerResolver(https://idp.example.org/issuerOne, https://idp.example.org/issuerTwo);http.authorizeHttpRequests(authorize - authorize.anyRequest().authenticated()).oauth2ResourceServer(oauth2 - oauth2.authenticationManagerResolver(authenticationManagerResolver));
这很好因为发行者端点的加载是延迟的。事实上相应的 JwtAuthenticationProvider 只有在发送第一个请求的时候才会被实例化。这使得应用程序的启动与这些授权服务器的启动和可用性无关。
2.1、动态租户
当然你可能不想在每次添加新租户时都重启应用程序。在这种情况下你可以用一个 AuthenticationManager 实例库来配置 JwtIssuerAuthenticationManagerResolver你可以在运行时编辑它就像这样。 Java
private void addManager(MapString, AuthenticationManager authenticationManagers, String issuer) {JwtAuthenticationProvider authenticationProvider new JwtAuthenticationProvider(JwtDecoders.fromIssuerLocation(issuer));authenticationManagers.put(issuer, authenticationProvider::authenticate);
}// ...JwtIssuerAuthenticationManagerResolver authenticationManagerResolver new JwtIssuerAuthenticationManagerResolver(authenticationManagers::get);http.authorizeHttpRequests(authorize - authorize.anyRequest().authenticated()).oauth2ResourceServer(oauth2 - oauth2.authenticationManagerResolver(authenticationManagerResolver));
在这种情况下你构建 JwtIssuerAuthenticationManagerResolver其策略是获取给定发行者的 AuthenticationManager。这种方法允许我们在运行时从资源库在片段中显示为 Map中添加和删除元素。
简单地采用任何发行者并从中构建一个 AuthenticationManager 是不安全的。发行者应该是代码可以从可信的来源如允许的发行者列表中验证的。
2.2 只对 Claim 进行一次解析
你可能已经注意到这种策略虽然简单但也有代价那就是JWT被 AuthenticationManagerResolver 解析了一次然后又被 JwtDecoder 在后来的请求中再次解析。
这种额外的解析可以通过使用 Nimbus 的 JWTClaimsSetAwareJWSKeySelector 直接配置 JwtDecoder 来缓解。 Java
Component
public class TenantJWSKeySelectorimplements JWTClaimsSetAwareJWSKeySelectorSecurityContext {private final TenantRepository tenants; private final MapString, JWSKeySelectorSecurityContext selectors new ConcurrentHashMap(); public TenantJWSKeySelector(TenantRepository tenants) {this.tenants tenants;}Overridepublic List? extends Key selectKeys(JWSHeader jwsHeader, JWTClaimsSet jwtClaimsSet, SecurityContext securityContext)throws KeySourceException {return this.selectors.computeIfAbsent(toTenant(jwtClaimsSet), this::fromTenant).selectJWSKeys(jwsHeader, securityContext);}private String toTenant(JWTClaimsSet claimSet) {return (String) claimSet.getClaim(iss);}private JWSKeySelectorSecurityContext fromTenant(String tenant) {return Optional.ofNullable(this.tenants.findById(tenant)) .map(t - t.getAttrbute(jwks_uri)).map(this::fromUri).orElseThrow(() - new IllegalArgumentException(unknown tenant));}private JWSKeySelectorSecurityContext fromUri(String uri) {try {return JWSAlgorithmFamilyJWSKeySelector.fromJWKSetURL(new URL(uri)); } catch (Exception ex) {throw new IllegalArgumentException(ex);}}
}
一个假设的租户信息来源JWKKeySelector 的缓存以租户标识符ID为key。查询租户比简单地计算JWK Set端点更安全—查询作为一个允许租户的列表通过从JWK Set端点回来的key类型创建一个 JWSKeySelector — 这里的延迟查找意味着你不需要在启动时配置所有租户
上述密钥选择器是许多密钥选择器的组合。它根据JWT中的 iss claim 来选择使用哪个key选择器。
要使用这种方法请确保授权服务器被配置为包括 claim 集作为令牌签名的一部分。如果不这样做你就不能保证 issuer 没有被坏行为者改变。
接下来我们可以构建一个 JWTProcessor。 Java
Bean
JWTProcessor jwtProcessor(JWTClaimSetJWSKeySelector keySelector) {ConfigurableJWTProcessorSecurityContext jwtProcessor new DefaultJWTProcessor();jwtProcessor.setJWTClaimSetJWSKeySelector(keySelector);return jwtProcessor;
}
正如你已经看到的将租户意识下移到这个层次的代价是更多的配置。我们只是多了一点。
接下来我们仍然要确保你正在验证 issuer。但是由于每个JWT的 issuer 可能是不同的那么你也需要一个租户感知的验证器。 Java
Component
public class TenantJwtIssuerValidator implements OAuth2TokenValidatorJwt {private final TenantRepository tenants;private final MapString, JwtIssuerValidator validators new ConcurrentHashMap();public TenantJwtIssuerValidator(TenantRepository tenants) {this.tenants tenants;}Overridepublic OAuth2TokenValidatorResult validate(Jwt token) {return this.validators.computeIfAbsent(toTenant(token), this::fromTenant).validate(token);}private String toTenant(Jwt jwt) {return jwt.getIssuer();}private JwtIssuerValidator fromTenant(String tenant) {return Optional.ofNullable(this.tenants.findById(tenant)).map(t - t.getAttribute(issuer)).map(JwtIssuerValidator::new).orElseThrow(() - new IllegalArgumentException(unknown tenant));}
}
现在我们有了一个租户识别处理器和一个租户识别验证器我们可以继续创建我们的 JwtDecoder。 Java
Bean
JwtDecoder jwtDecoder(JWTProcessor jwtProcessor, OAuth2TokenValidatorJwt jwtValidator) {NimbusJwtDecoder decoder new NimbusJwtDecoder(processor);OAuth2TokenValidatorJwt validator new DelegatingOAuth2TokenValidator(JwtValidators.createDefault(), jwtValidator);decoder.setJwtValidator(validator);return decoder;
}
我们已经完成了关于解析租户的讨论。
如果你选择通过JWT请求以外的方式来解析租户那么你需要确保你以同样的方式来解决你的下游资源服务器。例如如果你是通过子域进行解析你可能需要使用相同的子域来解决下游资源服务器。
