Windows Authentication with Blazor Server

Thank you for the link, I'll review it. BTW, when I last started this app I used Blazor Web App template, because the Blazor Server App insisted on using .NET 6. I presume I should continue with the Blazor Web App template, unless your answer says otherwise.

Hi @Bruce (SqlWork.com) I've been working on following the documentation you provided at Configure Windows Authentication in ASP.NET Core (when I've not been involved in meetings), but I've run into a situation that I need some guidance on.

Later on, the referenced page there's a section titled, Launch settings (debugger). That section starts out with a Visual Studio tab (there's another one for .NET CLI, but I won't be following that path). It starts by saying to create a new Razor Pages or MVC app. I've already got the beginnings of a Blazor Web Application, with no authentication. However, if I have to, I could blow this all away and start over again (for the umpteenth time). Is this the way I should go?

The alternative, I think, is the next section titled, IIS. This one might work with what I've done so far, although the starter app I've begun as a proof-of-concept app, doesn't have a Web.Config file in it. Although I think that's pretty easy to add. Anyway, I know that my management would want to use IIS, rather than Kestrel (I'd like to use Kestrel, but I know that won't fly). Bottom line, should I follow the IIS path from that Microsoft Learn course you linked to?

when hosted with IIS/IISExpress, IIS does the authentication, and passes the authentication handle to the asp.net core middleware. the middleware uses the handle to get the user name and build the claim principal.

kestrel only has support for kerberos. the middleware supplied by the nuget package Microsoft.AspNetCore.Authentication.Negotiate supports kerberos authentication and building the claim principal.

server blazors default authentication just uses the claim principal hosted by HttpContext to initial the authentication state (it doesn't care how it was created).

with WASM, the authentication state can be passed to the client via persist state provider so the client knows the name and claims, it not useful for api calls. api calls use javascript to call the server, and the browser can supply the credentials. this is cleaner to the user if the hosting page requires windows authentication. this requires that the javascript sends the include credentials flag. see:

https://video2.skills-academy.com/en-us/dotnet/api/microsoft.aspnetcore.components.webassembly.http.webassemblyhttprequestmessageextensions.setbrowserrequestcredentials?view=aspnetcore-8.0

Hi @Bruce (SqlWork.com) I'm sorry, I'm not following what you said here and as so often happens I get pulled away to do other things, until I can get back to this 5 days later.

Anyway, I was thinking of using Blazor Server, not WASM. So, when you said:

server blazors default authentication just uses the claim principal hosted by HttpContext to initial the authentication state (it doesn't care how it was created).

I am still stumped because the "Configure Windows Authentication in ASP.NET Core" link talks about using either None or Individual, for Blazor Server application. It doesn't say anything about using Windows Authentication in a .NET 8 Blazor Server application. I am so sorry for being so dense in this.