Authentication Redirect Failing

[zachrybaker]

Creating new issue here but IS RELATED to this closed unresolved issue

The issue is that the authentication only seems to work when visited from the pre-core website address. Once my forms-based (but written via FederatedAuthentication.SessionAuthenticationModule for claims' sake) auth cookie is in place, both apps/Urls work fine. But until then the new app will fail because auth is required, and the auth redirect process falls over.

(A) ASP.NET web forms app, pre-system web adapters:

• https://localhost:44332
• Auth: forms. Login page is ssoLogin.aspx, It redirects to a 3rd site for SSO which redirects back after authentication to webforms app (to ssoLogin.aspx). This time the webforms app sees the authenticated user data, and creates a FormsAuthenticationTicket (cookie), then redirects back to yet another second/different user page (ssoUser.aspx) to match the SSO identity to an app ID - they may have more than one AppUser Id and if so they must choose on this page. With the AppUser Id determined, FormsAuthentication.RedirectFromLoginPage(AppUserId, false); was used to update the User.Identity.Name with the app id and then return to the original URL. A bit hacky to swap out the type of identity, as the author noted, but it worked.
• Uses a gutted customized ASP.NET membership provider,
• Standard Session provider (in-proc),
• Standard Profile provider.

(A') ASP.NET app, updated with system web adapters-integrated:

• same url, https://localhost:44332
• Auth modifications: Keep the SSO scheme. FormsAuthenticationTicket swapped for a list of claims that include the SSO id, an empty AppId, the session ID (explained below), role, put into a Forms ClaimsIdentity, made into a SessionSecurityToken of the ClaimsPrincipal, I use the FederatedAuthentication.SessionAuthenticationModule to write the token to cookie. The SSO and appUser Id sequence still happens, then the claims are updated for the actual AppId and the cookie written to again. Finally the user is redirected to the originally-requested URL.
• AddSystemWebAdapters with proxy support, AddRemoteAppServer (key and keyheader set), and AddAuthenticationServer (default options).
• Membership provider left alone,
• Session provider swapped for a custom flavor of the Redis-backed session state provider (to pub-sub a JSON session object so that it can be synced to a Blazor app),
• Profile provider replaced with a custom profile provider that also pub/subs to Redis to also sync with Blazor app. The provider actually uses Grpc across named pipes to a profile service (that happens to be running under the Blazor app process) to provide initial data from SQL and sync via Redis.

(B) BLAZOR SERVER, net8.0

• https://localhost:7207
• YARP set up with a catch-all to the web forms app at its address.
• use of AddCascadingAuthenticationState in app startup
• AddSystemWebAdapters with AddRemoteAppClient (with RemoteAppUrl, ApiKey and ApiKeyHeader appropriately set), as well as AddAuthenticationClient(true)

result:

As long as the original app address is hit first, to cause the auth sequence on its domain, everything works fine. I can have a tab for each application open, and see the cookies for ASP.NET_SessionId and FedAuth magically appear/update in the blazor app's cookie storage when the web forms app sets them. Not a problem there. Once auth is set, features in either app are faithfully served via the blazor's app url, so proxying seems content.

The problem is that the authentication sequence fails in the new app. Excerpts from what I see in the logs below.

Logs

[INF] Request starting HTTP/2 GET https://localhost:7207/ - null null [DBG] 3 candidate(s) found for the request path '/' [DBG] Endpoint 'Blazor /' with route pattern '/' is valid for the request path '/' [DBG] Endpoint '/_Host' with route pattern '' is valid for the request path '/' [DBG] Endpoint 'fallbackRoute' with route pattern '{**catch-all}' is valid for the request path '/' [DBG] Request matched endpoint '/_Host' [DBG] Received remote authentication response with status code "Found" [DBG] Remote service did not authenticate a user [DBG] AuthenticationScheme: Remote was not authenticated. [DBG] Policy authentication schemes did not succeed [INF] Authorization failed. These requirements were not met: DenyAnonymousAuthorizationRequirement: Requires an authenticated user. [INF] AuthenticationScheme: Remote was challenged. [INF] HTTP GET / RequestBody:

Responded in 14.4330 ms with 302: [INF] Request finished HTTP/2 GET https://localhost:7207/ - 302 0 null 16.4005ms [INF] Request starting HTTP/2 GET https://localhost:7207/ssoLogin.aspx?ReturnUrl=%2fsystemweb-adapters%2fauthenticate%3foriginal-url%3d%252F&original-url=%2F - null null [DBG] 1 candidate(s) found for the request path '/ssoLogin.aspx' [DBG] Endpoint 'fallbackRoute' with route pattern '{**catch-all}' is valid for the request path '/ssoLogin.aspx' [DBG] Request matched endpoint 'fallbackRoute' [DBG] Received remote authentication response with status code "Found" [DBG] Remote service did not authenticate a user [DBG] AuthenticationScheme: Remote was not authenticated. [DBG] Policy authentication schemes did not succeed [INF] Authorization failed. These requirements were not met: DenyAnonymousAuthorizationRequirement: Requires an authenticated user. [INF] AuthenticationScheme: Remote was challenged. [INF] HTTP GET /ssoLogin.aspx?ReturnUrl=%2fsystemweb-adapters%2fauthenticate%3foriginal-url%3d%252F&original-url=%2F RequestBody:

Responded in 6.4224 ms with 302: [INF] Request finished HTTP/2 GET https://localhost:7207/ssoLogin.aspx?ReturnUrl=%2fsystemweb-adapters%2fauthenticate%3foriginal-url%3d%252F&original-url=%2F - 302 0 null 8.1477ms [INF] Request starting HTTP/2 GET https://localhost:7207/ssoLogin.aspx?ReturnUrl=%2fsystemweb-adapters%2fauthenticate%3foriginal-url%3d%252FssoLogin.aspx%253FReturnUrl%253D%25252fsystemweb-adapters%25252fauthenticate%25253foriginal-url%25253d%2525252F%2526original-url%253D%25252F&original-url=%2FssoLogin.aspx%3FReturnUrl%3D%252fsystemweb-adapters%252fauthenticate%253foriginal-url%253d%25252F%26original-url%3D%252F - null null ...(another round trip, with a 302)... [INF] Request finished HTTP/2 GET https://localhost:7207/ssoLogin.aspx?ReturnUrl=%2fsystemweb-adapters%2fauthenticate%3foriginal-url%3d%252FssoLogin.aspx%253FReturnUrl%253D%25252fsystemweb-adapters%25252fauthenticate%25253foriginal-url%25253d%2525252F%2526original-url%253D%25252F&original-url=%2FssoLogin.aspx%3FReturnUrl%3D%252fsystemweb-adapters%252fauthenticate%253foriginal-url%253d%25252F%26original-url%3D%252F - 302 0 null 7.5173ms [INF] Request starting HTTP/2 GET https://localhost:7207/ssoLogin.aspx?ReturnUrl=%2fsystemweb-adapters%2fauthenticate%3foriginal-url%3d%252FssoLogin.aspx%253FReturnUrl%253D%25252fsystemweb-adapters%25252fauthenticate%25253foriginal-url%25253d%2525252FssoLogin.aspx%2525253FReturnUrl%2525253D%252525252fsystemweb-adapters%252525252fauthenticate%252525253foriginal-url%252525253d%25252525252F%25252526original-url%2525253D%252525252F%2526original-url%253D%25252FssoLogin.aspx%25253FReturnUrl%25253D%2525252fsystemweb-adapters%2525252fauthenticate%2525253foriginal-url%2525253d%252525252F%252526original-url%25253D%2525252F&original-url=%2FssoLogin.aspx%3FReturnUrl%3D%252fsystemweb-adapters%252fauthenticate%253foriginal-url%253d%25252FssoLogin.aspx%25253FReturnUrl%25253D%2525252fsystemweb-adapters%2525252fauthenticate%2525253foriginal-url%2525253d%252525252F%252526original-url%25253D%2525252F%26original-url%3D%252FssoLogin.aspx%253FReturnUrl%253D%25252fsystemweb-adapters%25252fauthenticate%25253foriginal-url%25253d%2525252F%2526original-url%253D%25252F - null null (one or two more 302's, the url growing, until finally a 404) [INF] Request starting HTTP/2 GET https://localhost:7207/ssoLogin.aspx?ReturnUrl=%2fsystemweb-adapters%2fauthenticate%3foriginal-url%3d%252FssoLogin.aspx%253FReturnUrl%253D%25252fsystemweb-adapters%25252fauthenticate%25253foriginal-url%25253d%2525252FssoLogin.aspx%2525253FReturnUrl%2525253D%252525252fsystemweb-adapters%252525252fauthenticate%252525253foriginal-url%252525253d%25252525252FssoLogin.aspx%25252525253FReturnUrl%25252525253D%2525252525252fsystemweb-adapters%2525252525252fauthenticate%2525252525253foriginal-url%2525252525253d%252525252525252F%252525252526original-url%25252525253D%2525252525252F%25252526original-url%2525253D%252525252FssoLogin.aspx%252525253FReturnUrl%252525253D%25252525252fsystemweb-adapters%25252525252fauthenticate%25252525253foriginal-url%25252525253d%2525252525252F%2525252526original-url%252525253D%25252525252F%2526original-url%253D%25252FssoLogin.aspx%25253FReturnUrl%25253D%2525252fsystemweb-adapters%2525252fauthenticate%2525253foriginal-url%2525253d%252525252FssoLogin.aspx%252525253FReturnUrl%252525253D%25252525252fsystemweb-adapters%25252525252fauthenticate%25252525253foriginal-url%25252525253d%2525252525252F%2525252526original-url%252525253D%25252525252F%252526original-url%25253D%2525252FssoLogin.aspx%2525253FReturnUrl%2525253D%252525252fsystemweb-adapters%252525252fauthenticate%252525253foriginal-url%252525253d%25252525252F%25252526original-url%2525253D%252525252F&original-url=%2FssoLogin.aspx%3FReturnUrl%3D%252fsystemweb-adapters%252fauthenticate%253foriginal-url%253d%25252FssoLogin.aspx%25253FReturnUrl%25253D%2525252fsystemweb-adapters%2525252fauthenticate%2525253foriginal-url%2525253d%252525252FssoLogin.aspx%252525253FReturnUrl%252525253D%25252525252fsystemweb-adapters%25252525252fauthenticate%25252525253foriginal-url%25252525253d%2525252525252F%2525252526original-url%252525253D%25252525252F%252526original-url%25253D%2525252FssoLogin.aspx%2525253FReturnUrl%2525253D%252525252fsystemweb-adapters%252525252fauthenticate%252525253foriginal-url%252525253d%25252525252F%25252526original-url%2525253D%252525252F%26original-url%3D%252FssoLogin.aspx%253FReturnUrl%253D%25252fsystemweb-adapters%25252fauthenticate%25253foriginal-url%25253d%2525252FssoLogin.aspx%2525253FReturnUrl%2525253D%252525252fsystemweb-adapters%252525252fauthenticate%252525253foriginal-url%252525253d%25252525252F%25252526original-url%2525253D%252525252F%2526original-url%253D%25252FssoLogin.aspx%25253FReturnUrl%25253D%2525252fsystemweb-adapters%2525252fauthenticate%2525253foriginal-url%2525253d%252525252F%252526original-url%25253D%2525252F - null null [INF] HTTP GET /ssoLogin.aspx?ReturnUrl=%2fsystemweb-adapters%2fauthenticate%3foriginal-url%3d%252FssoLogin.aspx%253FReturnUrl%253D%25252fsystemweb-adapters%25252fauthenticate%25253foriginal-url%25253d%2525252FssoLogin.aspx%2525253FReturnUrl%2525253D%252525252fsystemweb-adapters%252525252fauthenticate%252525253foriginal-url%252525253d%25252525252FssoLogin.aspx%25252525253FReturnUrl%25252525253D%2525252525252fsystemweb-adapters%2525252525252fauthenticate%2525252525253foriginal-url%2525252525253d%252525252525252F%252525252526original-url%25252525253D%2525252525252F%25252526original-url%2525253D%252525252FssoLogin.aspx%252525253FReturnUrl%252525253D%25252525252fsystemweb-adapters%25252525252fauthenticate%25252525253foriginal-url%25252525253d%2525252525252F%2525252526original-url%252525253D%25252525252F%2526original-url%253D%25252FssoLogin.aspx%25253FReturnUrl%25253D%2525252fsystemweb-adapters%2525252fauthenticate%2525253foriginal-url%2525253d%252525252FssoLogin.aspx%252525253FReturnUrl%252525253D%25252525252fsystemweb-adapters%25252525252fauthenticate%25252525253foriginal-url%25252525253d%2525252525252F%2525252526original-url%252525253D%25252525252F%252526original-url%25253D%2525252FssoLogin.aspx%2525253FReturnUrl%2525253D%252525252fsystemweb-adapters%252525252fauthenticate%252525253foriginal-url%252525253d%25252525252F%25252526original-url%2525253D%252525252F&original-url=%2FssoLogin.aspx%3FReturnUrl%3D%252fsystemweb-adapters%252fauthenticate%253foriginal-url%253d%25252FssoLogin.aspx%25253FReturnUrl%25253D%2525252fsystemweb-adapters%2525252fauthenticate%2525253foriginal-url%2525253d%252525252FssoLogin.aspx%252525253FReturnUrl%252525253D%25252525252fsystemweb-adapters%25252525252fauthenticate%25252525253foriginal-url%25252525253d%2525252525252F%2525252526original-url%252525253D%25252525252F%252526original-url%25253D%2525252FssoLogin.aspx%2525253FReturnUrl%2525253D%252525252fsystemweb-adapters%252525252fauthenticate%252525253foriginal-url%252525253d%25252525252F%25252526original-url%2525253D%252525252F%26original-url%3D%252FssoLogin.aspx%253FReturnUrl%253D%25252fsystemweb-adapters%25252fauthenticate%25253foriginal-url%25253d%2525252FssoLogin.aspx%2525253FReturnUrl%2525253D%252525252fsystemweb-adapters%252525252fauthenticate%252525253foriginal-url%252525253d%25252525252F%25252526original-url%2525253D%252525252F%2526original-url%253D%25252FssoLogin.aspx%25253FReturnUrl%25253D%2525252fsystemweb-adapters%2525252fauthenticate%2525253foriginal-url%2525253d%252525252F%252526original-url%25253D%2525252F RequestBody:

Responded in 5.2909 ms with 404.

I am hoping there is a solution/resolution here. The FedAuth approach to get claims in place seemed necessary to carry the session id to the circut to bootstrap the session subscription on the blazor side.

[zachrybaker]

Small update. I may have found a workaround for the Blazor scenario. A little hard to validate with the IISExpress/VS tooling falling over frequently...

What I discovered was that the swa authentication sequence was occurring for static files on the web forms side - so it was enforcing authentication policy and walking thru that for things it was sending thru the proxy, static files at that.

The secret seems to be to add a custom authorization policy to the fallback site (web forms) in the reverse proxy config, and defined that as a pass-thru (i.e. nothing enforced).

"ReverseProxy": {
  "Routes": {
    "fallbackRoute": {
      "ClusterId": "fallbackCluster",

and

            services.AddAuthorization(options =>
            {
                options.AddPolicy("passThruPolicy", policy =>  policy.RequireAssertion(context => true));
                options.FallbackPolicy = new AuthorizationPolicyBuilder()
                    .RequireAuthenticatedUser()
                    .Build();
            });

Initially I thought that the default authentication scheme was at fault, that I needed to do the following, but that turned out not to be the case. I include these here in case they assist someone else with a similar issue:

• At services.AddSystemWebAdapters.AddAuthenticationClient, set the first parameter for default scheme to false
• Modify _Imports.razor to require Authorization (using the remote app scheme).

@using Microsoft.AspNetCore.SystemWebAdapters.Authentication;
@attribute [Authorize(AuthenticationSchemes = RemoteAppAuthenticationDefaults.AuthenticationScheme)]

Blazor documentation still leaving a lot to be desired, this workaround seems to allow things to function, more or less. The redirects that cause the "attempting reconnection" blazor messages that appear when jumping from blazor to proxied app are alarming so I'll still need to figure out how to avoid that.