Authentication Redirect Failing

Question

Authentication Redirect Failing

zachrybaker opened this issue 4 months ago · 1 comments

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 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.