-
Notifications
You must be signed in to change notification settings - Fork 5.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Spring Security IPv6 issue - is there a global config setting? #16337
Comments
Ok, I know where I may have gone wrong! This bit here at the end of tokenResponseClient bean was overriding the default resolver, so I removed it from the bottom of the Bean.
Now I see Ipv6 in the Spring BFF too!
Is there a more global setting to ensure preference to Ipv6, as I know that if I don't use my custom resolver it will resolve to ipv4 |
The main issue is with Spring WebClient not defaulting / preferring the use of IPV6 because if I now do this I get an IPV4 address back:
|
Maybe premature, but this seemed to have solved it for me. I removed my old customipvconfig, and applied it globally, as I think I found the right bean, webClientCustomizer at the very bottom:
|
This did not work: Spring Security seems to be bypassing this global WebBuilder customizer, as I cannot see any logs from the implementation below:
|
No matter how hard I tried, the global WebClient.builder customiser did not work. So, I ended up using this
And calling it wherever I 'THOUGHT' a webclient was being used...(this did end up working on AWS, without a NAT G/W, on the IPV6 stack, with an IPV6 only egress gateway) Authorization Token Response
Refresh Token Response
Client Credentials Token Response
RestAPI - ReactiveJwtDecoder
I maybe missing adding this to TokenResponse for RPInitiatedLogout and BackChannelLogout - but I'm not entirely sure of the Spring Security internals for that |
Ok, after 2 days of trouble shooting, I've narrowed this down to being a Spring Security issue.
Goal:
To run secure login page, via a Spring BFF and Spring Rest API, on AWS (IPV6 stack)
Why IPV6 and not IPV4 - (i) it's a much more modern protocol, and (ii) avoids the $600+ annual cost of a NAT Gateway (for Ipv4)
Started in: July 2024 (I know it's been 6 months)
Environment
AWS
ECS - Fargate
Essentially running Docker Images - 2 of them, one for each App
The containers run in an AWS Private Subnet, wrapped around an AWS Security Groups (for better security)
I have an Ipv6 egress only gateway on the route tables in the private subnet (so Ipv6 calls can get out into the internet)
Observations:
Initially my Rest API was unable get an Auth0 public key, as it was timing out.
I found out that this was because my code was resolving to Ipv4, despite me configuring some settings in Java / Spring to prefer Ipv6.
In the end I had to write this code, to get it to work
Note that when calling the webclient I do use a blocking call (not recommended for Reactive non-blocking Spring Webflux), but this seems to work for me, and it seemed ok to me since I'm getting the key from Auth0 on an infrequent refresh cycle.
JwtConfig class - in Spring Rest API
IPV6 Utility class -
For creating the IPV6 web-builder
The most important thing for me to see here is the Resource address and whether that is an IPV6 address:
And in my logs I see this, and when I run this on AWS, all works as expected the Auth0 JwT key is retrieved
THE PROBLEM
Now the problem is with my Spring BFF
In my OauthAuthorizedManagerConfig class, I have the following code. I included the extra bean tokenResponseClient, to see if I could see and also set the webclient when the Spring BFF - Auth0 token exchange is done (to force preference to IPV6)
Here, I use the same Ipv6 Util class as I did in my Spring Rest API, with all the Spring / Java settings to prefer Ipv6.
The specific call to the ipv6 util webclient is here:
And the Spring BFF class itself...
OauthAuthorizedManagerConfig class
Internally when the webclient is set and called by WebClientReactiveAuthorizationCodeTokenResponseClient,
It does something like this (it doesn't use the block command, probably a red herring, but the only difference I noted to my Spring Rest API code)
But importantly, for some reason, the resolved address always ends up being an Ipv4 one (when using val jwkSetUri = URI(serverProperties.auth0JwKeySetUri) or val auth0TokenUri = URI(serverProperties.auth0TokenUri) as the input URL)
2024-12-22T20:23:22.774Z DEBUG 1 --- [BFFApplication] [or-http-epoll-2] c.v.b.a.m.OAuth2AuthorizedManagerConfig : Remote Address: dev-ld4xuyx1eigiqoge.uk.auth0.com/172.64.152.186:443
And this is the root cause of the issue...
The request won't pass out of the AWS Environment (unless I add a NAT Gateway, to allow outbound Ipv4 requests from a Private Subnet)
Not an Auth0 issue
If I take the JwtConfig class, from my Spring Rest API and place a copy of it in my Spring BFF container, that still resolves to IPV6. (when using val jwkSetUri = URI(serverProperties.auth0JwKeySetUri) as the input URI to createIpv6WebClient() ) - so that rules this out as being an Auth0 issue.
It is more an issue with the tokenResponseClient class, and the way the webClient is being called, which I cannot pin down.
I imagine there might be a few webclients all over the Spring BFF, which call auth0 endpoints here and there (see below), apart from the tokenResponseClient bean. But for some reason, at least the tokenResponseClient bean above it is not resolving to IPV6 - which is causing problems.
Is anyone from the Spring Security team able to provide guidance or help? Maybe they can see an issue with my configuration or code?
Many thanks in advance
Spring BFF Auth0 endpoints
Endpoints being called that may potentially be calling webclients supporting / not preferring IPV6, unless here is a global configuration for this, that needs to be put into a particular class.
The text was updated successfully, but these errors were encountered: