Closed ym-91 closed 3 weeks ago
Are you using server-side clients? Then the requests to the endpoints you mention are probably back-channel requests. They are not initiated by a browser but by the server application hence the absence of the user-agent header. Is there a way to make an exception to the rule?
@ym-91 Would you like to follow up? If not I'd like to close this issue.
Hi Roland, Thanks for your reply. I'll take a look to our server application configuration and let you know asap.
We enabled the ForwardedHeaders option in the configuration of the application server (XForwardedFor, XForwardedProto and XForwardedHost) and it seems to work now. You can close this issue. Thanks for your help!
Which version of Duende IdentityServer are you using? 6.2.3
Which version of .NET are you using? 7.0
Describe the bug
We are currently trying to implement a more powerful firewall, AWS WAFV2, in order to increase security for our business applications. In this context, we have deployed a new set of rules in our UAT environment.
However, one of the rules is blocking our corporate SSO and preventing it from working at all. This is the managed set of rules named "AWSManagedRulesCommonRuleSet", which requires HTTP calls to systematically present a header with a populated User-Agent, which doesn't seem to be the case at least on 2 different routes of our SSO:
/connect/token (method: POST) Accept: application/json Content-Type: application/x-www-form-urlencoded
/.well-known/openid-configuration (method: GET)
Is there a way to force display user-agent on every calls?
I cannot tell for sure that the user-agent's missing behavior is also present on other routes of our corporate SSO.
To Reproduce
Load the routes and look for user-agent on your browser.
Expected behavior
User-agent should be available on every calls.
Log output/exception with stacktrace
Not available.
Additional context