Узнать о том, что запрашиваемый ресурс требует аутентификации, клиент может не раньше, чем запросив этот ресурс. Для чего и служит HTTP код 401. Этот код должен сопровождаться подробностями о том, какая аутентификация ожидается. Не рассматривая здесь Kerberos, как правило, применяются 4 варианта : 1). NTLM (Windows Integratated). 2).Basic, 4), Forms и 4) Digest. Относительно первого, сразу заметим, что он не поддерживается  несколькими версиями Windows Vista, включая Vista Home Premium, а в остальном, это, пожалуй, наиболее распространенный способ аутентификации в мире Intranet и IIS .Ответ сервера, ресурс которого требует WindowsIntegrated Authentication выглядит так:
 

Здесь HTT- header WWW-Authenticate содержит т.наз. "challenge", который клиенту (в том числе браузеру) нужно теперь отправить на NTLM Manager, используя credentials текущего user для шифрования. В ответ NTLM Manager вернет token, который теперь клиент передаст серверу, начиная тем самым вторую фазу аутентификации. Сравнивая переданный challenge с полученным token, сервер решает, может ли эта пара быть признана аутенфикацией клиента, и, в случае положительного решения, дело заканчивается возвратом 200 с ожидаемым ресурсом. В противном случае, клиент получит 401 еще раз без WWW-Authenticate header'a, что является свидетельстовом того, что дальнейшие попытки аутентифицироваться от него больше не ожидатеся. В любом случае,NTLM  не передает по сети клиентских credentials, чем и выгодно отличается от второго способа аутентификации - Basic .

В этом случае, серверный 401 содержит WWW-Authenticate header'e значениe "Basic realm=XXX", что означает, что от клиента в ответ (на второй фазе) требуется передача пары user_name:password, которые идентифицируют клиента внутри realm XXX. Сервер сам ответственен за ведение и учет клиентских записей в этом случае, а также, понятно, за проверку полученной пары среди своих записей. Для передачи пары используется base64 кодирование.

Реагируя на серверный 401 с WWW-Authenticate , браузеры обычно показывают окно, в котором (с соответствующим предупреждением) пользователю предлагается ввести свои credentials, для BizTalk host instance, который вызывает, скажем, Web service, соответствующие credentials настраиваются на уровне Send Port, но могут быть установлены и из оркестрации с помощью SOAP.UserName, SOAP.Password и SOAP.AuthenticationScheme properties.

[414x459]
 

Обычно ни тот, ни другой способ не являются достаточно гибкими для решений BizTalk, поэтому часто в случае basic authentication  прибегают к SSO, который транслирует credentials учетной записи hosta в credentials, пригодные для проверки в web realm. Разумеется,SSO ничего не меняет в HTTP- протоколe.

 Во всех случаях аутентификации, клиентский код использует <proxy>.Credentials для этих целей (обычно устанавливая это в System.Net.CredentialCache.DefaultCredentials)