ClickOnce problems: Windows Authentication and the ClickOnce boot-strapping process

I was testing my "Hello World" application today and validating that it worked correctly with the ClickOnce deployment tools and with our SharePoint setup.  The requirements of the final application include that it be launchable from external partner sites and via a secure SharePoint site (over HTTPS, using NTLM authentication).  I discovered that this is not a well-covered scenario and the ClickOnce works only for users logged into domain account (on domain-joined machines), and in some cases, when they are in the same enterprise (domain forest).  This really surprised me.  And the latter issue also blocked me personally as well from using my test "deployment" because of the peculiarities of my own domain account and the group I am currently working in.  I'll explain the problem below ...

After reading the MSDN articles, I found out that ClickOnce only supports NTLM "Windows Authentication" when using HTTP/S.  This means that no other authentication methods will work, except for no authentication.  Furthermore, the default Windows log-on credentials are used.  If the HTTP/S request fails, then the "boot loader", which handles the downloading and initialization of the application, fails.

There are two situations in which this does not work: the first is where the user is not logged into a domain account, and has opened the application's deployment URL via Internet Explorer.  IE will graciously ask for difference credentials if the default ones do not work.  The ClickOnce bootloader is not so intelligent, at least in .Net Framework 2.0.  So the application manifest is visible to the user in IE, but not to the ClickOnce bootloader.

The second situation is if your domain credentials are for some reason not good enough.  There are cases where the domain needs to be fully specified for the authentication to succeed. For example, I may log in as DOMAIN1\Brian, but in order to properly authenticate with the server, I need to provide my name as brian@DOMAIN1.subdomain.mycompany.com, giving the fully qualified domain name.  Why is this?  I have not bothered to find out, it is some problem with how the domains authenticate with each other. However it is definitely annoying and does not seem consistent.

To summarize these limitations let me say that ClickOnce will work in the following cases: no authentication, custom application authentication (not officially supported) or NTLM authentication.  I was really disappointed by this because in my situation, there is no work around.  The users will not be using domain joined machines, and I cannot give open access to the SharePoint deployment site due to IP requirements and company policy (obvious).  Likewise, custom authentication methods (or the HTTP proxy solution suggested by the article) are just not adequate.  Anything non-standard or less than secure is just not an answer to be considered. 

The article below talks about the authentication mechanisms used and possible work-arounds to authentication issues:

https://msdn2.microsoft.com/en-us/library/aa480721.aspx

For now, I'm going to have to deploy my application as a traditional MSI package and implement an updater to keep the client machines up to date as new versions of the software package is created.  This will probably involve using the Updater Application Block.