Describe the bug
When using the remote authentication which was included in a recent update, after the authentication is complete, when the /systemweb-adapters/authenticate endpoint is loaded, an IIS HTTP 407.0 Proxy Authentication Required page is displayed. After this error page is loaded, any attempt to go to any URL, whether it ends up loading the new ASP.NET Core application, or if it loads the old ASP.NET application, works without any further issues, with the user properly authenticated. Also, the Logon User field on the error page does properly list the username of the person logged in.
This application is not using forms authentication nor bearer jwt. It is instead making use of the WsFederationAuthenticationModule and SessionAuthenticationModule to allow federated login. As I have it set up, the original ASP.NET application ran on localhost:44378, and the STS is set up to post the token to localhost:44378/, which would be processed by the WsFederationAuthenticationModule. After the migration, the new ASP.NET Core application runs on localhost:44395. When a challenge occurs, a redirect to the STS with the proper WS-Federation supplied information does occur, I am able to log in via the STS, and it posts the data to localhost:44378/, which properly processes the token, and then redirects to localhost:44378/systemweb-adapters/authenticate, at which point the Proxy Authentication Required page appears. Attempting to reload localhost:44395 works with the logged in user information available.
I also attempted changing the STS to post the token information to localhost:44395/signin-wsfed (in order to make sure the request gets properly forwarded to the ASP.NET application rather than being handled by the default razor page in ASP.NET Core), the result is exactly the same, with the exception that the Proxy Authentication Required page is loaded from localhost:44395/systemweb-adapters/authenticate. Also, just like before, reloading localhost:44395 after this results in proper authenticated access.
I do not have enough information to determine if this issue is caused by trying to use this with WsFederationAuthenticationModule, or if this is due to having something else not set up properly.
To Reproduce
After performing a migration via the VS extension and then updating the SystemWebAdapters package to a locally built package containing the remote authentication implementation, I added code to enable the remote authentication.
ASP.NET Core application
.AddRemoteAppAuthentication(true, opts => {
opts.RemoteServiceOptions.ApiKey = "Some secret key";
opts.RemoteServiceOptions.RemoteAppUrl =
new(builder.Configuration["ReverseProxy:Clusters:fallbackCluster:Destinations:fallbackApp:Address"])
;
})
ASP.NET Application
.AddProxySupport(opts => {
opts.UseForwardedHeaders = true;
})
.AddRemoteAppAuthentication(opts => {
opts.RemoteServiceOptions.ApiKey = "Some secret key";
})
Further technical details
Please include the following if applicable:
ASP.NET Framework Application:
- Technologies and versions used (i.e. MVC/WebForms/etc): WebForms
- .NET Framework Version: 4.7.2
- IIS Version: 10 Express
- Windows Version: 10
ASP.NET Core Application:
- Targeted .NET version: 6.0
- .NET SDK version: 6.0.300
Describe the bug
When using the remote authentication which was included in a recent update, after the authentication is complete, when the
/systemweb-adapters/authenticateendpoint is loaded, an IIS HTTP 407.0 Proxy Authentication Required page is displayed. After this error page is loaded, any attempt to go to any URL, whether it ends up loading the new ASP.NET Core application, or if it loads the old ASP.NET application, works without any further issues, with the user properly authenticated. Also, the Logon User field on the error page does properly list the username of the person logged in.This application is not using forms authentication nor bearer jwt. It is instead making use of the
WsFederationAuthenticationModuleandSessionAuthenticationModuleto allow federated login. As I have it set up, the original ASP.NET application ran on localhost:44378, and the STS is set up to post the token to localhost:44378/, which would be processed by theWsFederationAuthenticationModule. After the migration, the new ASP.NET Core application runs on localhost:44395. When a challenge occurs, a redirect to the STS with the proper WS-Federation supplied information does occur, I am able to log in via the STS, and it posts the data to localhost:44378/, which properly processes the token, and then redirects to localhost:44378/systemweb-adapters/authenticate, at which point the Proxy Authentication Required page appears. Attempting to reload localhost:44395 works with the logged in user information available.I also attempted changing the STS to post the token information to localhost:44395/signin-wsfed (in order to make sure the request gets properly forwarded to the ASP.NET application rather than being handled by the default razor page in ASP.NET Core), the result is exactly the same, with the exception that the Proxy Authentication Required page is loaded from localhost:44395/systemweb-adapters/authenticate. Also, just like before, reloading localhost:44395 after this results in proper authenticated access.
I do not have enough information to determine if this issue is caused by trying to use this with
WsFederationAuthenticationModule, or if this is due to having something else not set up properly.To Reproduce
After performing a migration via the VS extension and then updating the SystemWebAdapters package to a locally built package containing the remote authentication implementation, I added code to enable the remote authentication.
ASP.NET Core application
ASP.NET Application
Further technical details
Please include the following if applicable:
ASP.NET Framework Application:
ASP.NET Core Application: