Автономный сайт на основе HttpListener — как обрабатывать аутентификацию?

#c# #.net #security #httplistener #self-hosting

#c# #.net #Безопасность #httplistener #автономный хостинг

Вопрос:

Если вы создаете автономную веб-страницу HttpListener , как вы можете безопасно обрабатывать аутентификацию? Я не хочу использовать базовую аутентификацию, потому что она передает учетные данные в виде открытого текста. Я знаю, что дайджест — это еще один вариант,

         listener = new HttpListener();
        listener.Prefixes.Add(url);
        listener.AuthenticationSchemes = AuthenticationSchemes.Digest; 
        listener.Start();
  

Достаточно ли это безопасно и каковы стандартные / рекомендуемые методы для фактического получения имени пользователя / пароля и их аутентификации?

В этой ситуации по умолчанию отсутствует web.config или среда хостинга.

Комментарии:

1. наилучшей практикой было бы использовать HTTPS / SSL. Вы избегаете IIS и создаете свой собственный веб-сервер, подобный компоненту? Могу я спросить, почему просто для любопытства? 🙂

2. Я работаю над веб-приложением, в значительной степени управляемым событиями и работающим в режиме реального времени (представьте себе чат-сервер, но с большей функциональностью), используя реактивные расширения и цикл событий (например, как node.js работает). Возможно, я каким-то образом интегрирую его в IIS в какой-то момент, но пока это просто проект с голыми костями. Что касается использования SSL, который настраивается с помощью HttpListener, но как насчет обработки учетных данных пользователя?

3. Хотя легко представить, почему: приложение, которое не требует IIS, например, приложение WinForms, которое может предоставлять веб-интерфейс, просто чтобы вы могли получить доступ к приложению с помощью веб-браузера.

4. I don't want to use Basic Authentication because it passes credentials as clear text . Это не проблема, если вы используете https

Ответ №1:

Использование аутентификации с помощью HttpListener означает, что Windows выполняет вашу аутентификацию за вас, используя встроенную систему аутентификации (например, ActiveDirectory). Это означает, что для дайджест-аутентификации вам необходимо создать учетные записи домена для ваших пользователей. Это то, что вы намеревались? Если вы хотите выполнить свою собственную пользовательскую аутентификацию, это более сложный вопрос. Я не буду вдаваться в подробности, как это сделать, если вы не скажете, что это то, что вы хотите сделать.

Комментарии:

1. Спасибо. Я, скорее всего, собираюсь использовать digest, по крайней мере, на данный момент. Я просто беспокоился о том, достаточно ли он безопасен. Знаете ли вы какие-либо ссылки, объясняющие, как использовать дайджест-аутентификацию active directory? Или digest делает это из коробки?

2. Из коробки. Грубо говоря, если вы настроили HttpListener и не разрешаете анонимную аутентификацию, HttpListener вернет 401 не прошедшим проверку подлинности пользователям, и заголовки запустят протокол аутентификации. Затем в браузере появится диалоговое окно входа в систему. Пользователь вводит учетные данные. Сервер попытается аутентифицировать пользователя с помощью ActiveDirectory. Учетные данные должны быть действительными, и учетной записи потребуются любые разрешения, необходимые для входа в систему таким образом (я не помню, какие разрешения требуются, но это где-то задокументировано.)

3. Ваш код вообще не видит запрос, пока пользователь не пройдет аутентификацию.

Ответ №2:

Я бы рассмотрел возможность реализации поддержки безопасности на основе утверждений. Вам придется обрабатывать токены безопасности, но фактическая аутентификация пользователя может быть «передана» внешним поставщикам удостоверений.

Вероятно, вы могли бы использовать Windows Identity Foundation (WIF) для выполнения большей части работы.