Add Support DPoP Customization
Closes gh-16940
Thanks for the PR @franticticktick. I will review this soon.
Thanks for your patience @franticticktick and apologies that I could not get this into 7.0. We had quite a workload for this round of majors.
I have scheduled this for 7.1.0-M1 and will review this soon. In the meantime, when you have a moment can you please rebase. Thank you.
@franticticktick @jgrandja I haven't gone through the details of the PR, but I just wanted to add the following:
It's not uncommon for ppl to have a reverse proxy in front of their applications, having a reverse proxy could mean (like in my use case) that you have different paths per application. For example, https://api.example.com/svc1/* routes requests to application svc1 and https://api.example.com/svc2/*routes requests to application svc2. The problem here is that normally applications would sign the DPoP for https://api.example.com/svc2/my-api and not https://api.example.com/my-api. So when Spring Security's DPoP validation kicks in, it will look at the URL https://api.example.com/svc2/my-api and find no endpoint matching that URL, because the application doesn't know about /svc2/my-api. Now our current workaround is that our frontends replace the first path segment of the URL so that they send the request to /svc2/my-api, but sign the DPoP for /my-api, but IMHO frontends should be aware of the reverse proxy whatsoever.
TL;DR it should be possible to customize the DPoP validation to be reverse-proxy aware. I'm just trying to scratch my itch here, but I do believe this is not an uncommon use case. I'm happy to contribute somehow if needed.
Edit:
Also, can we also get this into the 6.5.x?
TL;DR it should be possible to customize the DPoP validation to be reverse-proxy aware. I'm just trying to scratch my itch here, but I do believe this is not an uncommon use case. I'm happy to contribute somehow if needed.
I've a similar setup where reverse proxy is Spring Cloud Gateway 5 MVC. You must configure your reverse proxy to add X-Forwarded-xxxx headers (in your case, X-Forwarded-Prefix should report /svc1 or /svc2 to your resource server).
In my setup, I've configured my resource server with server.forward-headers-strategy = framework and it works as expected (see Running Behind a Front-end Proxy Server)
@ferrerogg it worked. Thank you so much!