Windows Authentication for Blazor Server app

The

Note: I had to run a netsh http add urlacl url=.... one time only; the command was suggested by an exception message generated on first run after changing the launch URL.

Entering my domain login username and password is accepted, and the previous code sample does show my username successfully. I also noticed the following behaviour:

setting AllowAnonymous = true; means it will not prompt at all for the username/password; the page just proceeds with the user not authenticated.

If the username/password is not entered correctly (for a user on the domain) then HTTP error 401 is generated instantly, it never tries to execute the Blazor default error page for example.

I hope the authentication is being done between the client and the domain controller, not sending the user's password over the HTTP connection!

I am presuming the above behaviour will be the same for other domain uses on different machines accessing this server, although have not tested that yet.

My questions:

is it possible to skip the username/password popup , and just get the domain user that is already logged in on the client machine and doing the access?

(If not) would deploying to IIS instead of Http.Sys change anything?

There seem to be Blazor-based solutions discussed on this SO thread , but I can't see how to use them because the popup always appears as soon as any page is attempted , before any page is rendered; and if login fails, HTTP 401 error is generated with none of the Blazor pages being executed.

CodePudding user response：

is it possible to skip the username/password popup , and just get the domain user that is already logged in on the client machine and doing the access?

IMHO, this is not possible with "windows authentication", because the popup dialog that you see is a special browser feature to enable the windows authentication.This one created in order to support internal application with domain authentication. I don't know of any way to access that browser behavior.

(If not) would deploying to IIS instead of Http.Sys change anything?

Haven't done a deployment with Http.Sys, but according to the documentation it says that Http.Sys supports windows authentication. The deployment would be different since for Http.Sys you need to write the configuration in code, unlike the IIS.

CodePudding user response：

This is a client-side issue.

If I launch the application on http://localhost:55555 then the page loads instantly and it shows my domain and username successfully.

However, if I launch the application as http://mycomputername.our.domain:55555, and access it via Chrome or Edge on the same machine, then a popup appears asking for username and password:

That's because the browser recognizes localhost as a (somewhat trustworthy) server within your intranet, but considers mycomputername.our.domain to be a (potentially hostile) Internet service. For security reasons, Chrome and Edge only use your Windows credentials with servers within your own intranet by default.

To determine which group an URL belongs to, Chrome, Internet Explorer and Edge use Windows's own "Intranet zone" settings. To add your URL,

search for "Internet options" in the Windows Start Menu, then

navigate to Security/Local intranet/Sites/Advanced.

If you want to test with a non-Chromium based browser, here's how to configure Firefox. Firefox manages its own list of URLs where Windows authentication is allowed:

How to configure Firefox for NTLM SSO (Single-Sign-On)?

I hope the authentication is being done between the client and the domain controller, not sending the user's password over the HTTP connection!

If the client and the server agree to use Kerberos, sure: The client communicates with the domain controller to authenticate and to get a service ticket and then uses that ticket to access your service.

If they don't agree, they will use NTLM. In this case, authentication happens between the client and your server. However, NTLM won't send your password in plain text either, but rather uses it as part of a challenge-response mechanism.