Is it possible to configure multiple SecurityConfigurations?
With SecurityConfigurations its possible to set the Client-ID and Secret for OAuth client:
#Bean
fun swaggerSecurityConfiguration() =
SecurityConfigurationBuilder.builder()
.clientId(CLIENT_ID)
.realm(REALM)
.appName(APP_A)
.additionalQueryStringParams(mapOf("nonce" to UUID.randomUUID().toString()))
.build()
For a single client it works like charm:
Question: How to configure springfox in case you have multiple oauth2 client Id?
#Bean
fun api(): Docket {
return Docket(DocumentationType.SWAGGER_2)
// ...
.securitySchemes(listOf(appA_AuthSecuritySchema(), appB_AuthSecuritySchema()))
.securityContexts(listOf(appA_AuthSecurityContext(),appB_OAuthSecurityContext()))
}
I couldn't find any way to relate the securitySchemas to different SecurityConfigurations.
Have you considered splitting your API into multiple dockets with each getting its open security setup?
Some additional information here: Configure security schemas and contexts in Springfox and Spring MVC
By the way, just an FYI, but Springfox is dead. I resisted moving off of it for a while, hoping the guy would come around because it seemed like a big task to migrate to SpringDoc. The migration wasn't too bad actually and I was using a lot of Springfox annotation functionality. Springfox has got lots of issues and no support. Almost 700 open issues. Plus you'll be stuck in the Swagger2 realm forever with Springfox when everything has moved on to Open API.
As per my knowledge, it's not possible in springfox and I also did some R&D and find this git issue so you can find form the Below issue it's already closed issue so please check it this git issue.
https://github.com/springfox/springfox/issues/959
Thanks!
Karmdip J.
Related
Update
this issue is now assigned to CVE-2022-22965. Other than below nice answers, please do check Spring Framework RCE: Early Announcement as it is the most reliable and up-to-date site for this issue.
According to different source, seems we got a serious security issue when using Spring Core library.
https://securityboulevard.com/2022/03/new-spring4shell-zero-day-vulnerability-confirmed-what-it-is-and-how-to-be-prepared/
Quoting from above link, we are in risk if:
You use a Spring app (up to and including version 5.3.17)
Your app runs on Java 9+
You use form binding with name=value pairs – not using Spring’s more popular message conversion of JSON/XML
You don’t use an allowlist –OR– you don’t have a denylist that blocks fields like “class”, “module”, “classLoader”
The link suggested to some solution but doesn't seems easy to implement/reliable.
What should we do to fix this issue, in easiest and most reliable way?
According to the Spring Framework RCE: Early Announcement, upgrading to Spring Framework 5.3.18 or 5.2.20 will fix the RCE.
If you use Spring Boot, Spring Boot 2.5.12 and Spring Boot 2.6.6 fixes the vulnerability.
If you're unable to update:
You can choose to only upgrade Tomcat. The Apache Tomcat team has released versions 10.0.20, 9.0.62, and 8.5.78 all of which close the attack vector on Tomcat’s side.
If you can't do any of the above, the RCE announcement blog post suggests a workaround: Set disallowedFields on WebDataBinder through an #ControllerAdvice:
#ControllerAdvice
#Order(Ordered.LOWEST_PRECEDENCE)
public class BinderControllerAdvice {
#InitBinder
public void setAllowedFields(WebDataBinder dataBinder) {
String[] denylist = new String[]{"class.*", "Class.*", "*.class.*", "*.Class.*"};
dataBinder.setDisallowedFields(denylist);
}
}
This quick fix will not work if a controller sets disallowedFields locally through its own #InitBinder method, which overrides the global setting. Also, more generally, the workaround will not have an effect if you use alternate REST frameworks such as Jersey (however, it has not yet been demonstrated that such configurations are impacted).
Note: Spring upgrade is needed later on as vulnerability is not in Tomcat
Temporary Workaround is Upgrade tomcat to 10.0.20, 9.0.62, and 8.5.78
Spring Reference
it's a confusing problem but suffered me several days.
Firstly, I got to know that the new spring security oauth2 is changed, then I come to learn:https://docs.spring.io/spring-security-oauth2-boot/docs/2.5.2/reference/html5/.
However, when I try to add the annotation #EnableAuthorizationServer to the "main method", the Intellij throws it's deprecated".
Then, I tried to check the version: springframework.boot:2.5.2 , spring-security-oauth2:2.5.1.RELEASE, spring-security-oauth2-autoconfigure:2.5.2.
It means all the dependencies are new, and the doc is new too.
Then why the Intellij says the annotation is deprecated? I just wanna follow the new trend. Please tell me what to do?
thanks a lot.
As the documentation to which you have linked states, the project is in maintenance mode. Where possible, it should not be used and the equivalent features in Spring Security 5.x should be used instead.
The deprecation message on EnableAuthorizationServer links to a migration guide. From there you can learn about the Spring Authorization Server project which you may want to use.
The code-base I work with has a working OAuth model that uses OAuth2RestTemplate to manage access-tokens & access-token requests. As OAuth2RestTemplate is deprecated, I want to move to Spring Security OAuth & WebClient.
When I looked at some of the classes involved, I was surprised to see that OAuth2AccessTokenResponseClient does not return a Mono, and the default implementation - DefaultPasswordTokenResponseClient - uses RestTemplate internally.
I thought one of the primary advantages of WebClient was that it was non-blocking? If that is the case, why is blocking I/O one of the default strategies for requesting access-tokens? From the perspective of someone new to reactive/WebClient, I do not understand why the OAuth2AccessTokenResponseClient isn't itself a WebClient instance.
If I try to write a custom filter that uses WebClient to request the token, will I encounter major roadblocks or hard-to-detect bugs? I do not have much knowledge to build off in this area but would still appreciate if someone could try to help out.
You are wrong a little: OAuth2RestTemplate is not deprecated; since Spring version 2.2.0 plenty classes are moved to new and other libraries, Spring left in OAuth module only the Authentication server, all other classes annotated as deprecated. OAuth2RestTemplate is used further, just with another package.
In light of this you can use RestTemplate further, but with changes in a project. Or, of course, to move to WebClient. This approach is not better or worse, it's just can work asynchronous and non-blocking.
We in our projects decided while not to move to new version, waiting for clear and fully understandable documentation about migration (at least last month it was not full and not fully understandable).
I am having an architectural issue with the Apache HttpComponents HttpClient.
We have a system where we have several different remote endpoints that we want to contact, and each have some different configurations like ssl, basic auth, et cetera.
I am using Spring Boot and Cloud Sleuth from which I get a HttpClientBuilder that gives me tracing and other things. I want to re-use that HttpClientBuilder but on-top of that add my own specific configurations, for each unique endpoint.
The problem though is that the HttpCientBuilder is not immutable with withXYZ() methods, nor is there a copy or clone method on the builder, so I can't copy the original and change just my specific changes there without altering the base HttpClientBuilder and get into conflicts with others that use the same instance of the builder. Be it racing conditions between threads or conflicting configurations between the different endpoints.
One place in the Spring Boot project where I have seen them seemingly wanting to do something similar is in HttpClientConfiguration of Spring Cloud Commons where it creates an own ApacheHttpClientFactory which takes the original autowired HttpClientBuilder and then sets disableContentCompression(), disableCookieManagement() and useSystemProperties() -- but it seemingly does it to the original instance of the HttpClientBuilder which just seems completely wrong to me. It will alter how all the built HttpClient works, and not just the one they will later be using in their Ribbon code in HttpClientRibbonConfiguration of Spring Cloud Netflix Ribbon. A potential bug in hiding? To me it seems like it, since it highly depends on calling order.
Does anyone have any ideas how something like this should be solved?
The easy alternative that I could do is to just not try and build upon the given HttpClientBuilder from Sleuth, but instead build a completely new one from the ground-up every time I need one, and check if a HttpTracing bean is available and use TracingHttpCientBuilder instead of HttpClientBuilder in that case, but this seems counter-intuitive.
I ran into the exact same problem. However, I had the option of defining my own HttpClientBuilder bean. I am not sure you are in the same position?
But by making the bean scope "prototype" a new bean instance is created every time it is injected somewhere. Then I could safely modify the HttpClientBuilder after injection.
#Bean
#Scope("prototype")
public HttpClientBuilder tracingHttpClientBuilder(..) {
...
}
The following example https://github.com/graphql-java/graphql-java-subscription-example which use's graphql-java for subscriptions over a websocket.
How can the same idea be done within the spring version? GraphQLSubscriptionResolver needs to return a publisher but I am unable to work out how this can then be used with a web socket.
The example above seems fine within a none spring version.
A good friend of mine has made an example in his github repository.
The code is not the nicest (because it was for our own personal needs) but it is a nice example
Have fun
Here's a port of the graphql-java example using GraphQL-SPQR with Spring Boot. I'll soon merge it into the GraphQL-SPQR samples project.
Same as with the other answer, while it uses GraphQL-SPQR to generate the schema, the Spring and websockets bit is the same as you'd have with graphql-java directly.
There's now a new and somewhat more realistic example using GraphQL SPQR Spring Boot Starter. It publishes updates when a relevant mutation runs.
I just published a workshop in which you can learn how to implement the subscription operations.
http://graphql-java.wesovilabs.com
Let me know If you have any doubt
I hope you find it useful!
Thanks