Comments 22
В этом случае пользователю не придется дополнительно что-либо вводить для аутентификации: браузер автоматически аутентифицируется используя Kerberos тикет, полученный от AD при логине в Windows (по сути это вариант аутентификации по токену). На стороне веб-приложения мы сможем получить информацию о доменном аккаунте аутентифицированного пользователя.
AD-аутентификация — да, она реализуется через схему Negotiate. Но у нее есть недостатки — к примеру, нормально работать с этой схемой может только IE — остальным браузерам понадобится другой способ аутентификации и никакого SSO в итоге не случится.
Поэтому если нужно сделать SSO — надо использовать WS-Federation или OpenID-connect, а уже на стороне Identity Provider можно применить Negotiate как один из вариантов внутренней аутентификации.
Используем в паре проектов — вы не представляете, насколько ниже нагрузка на сопровождающих:
нет ввода пароля — нет его «забывания» и неправильного ввода, блокировок и заявок на разблокировку…
Если пользователь вошёл в домен — значит может и работать в программе.
Один момент только портит всю картину — иногда по непонятным причинам (при заливке и скачиваниии файла) у пользователя IE идёт запрос пароля. Админы домена не могут ничего путного сказать…
При этом у тех, кто переносит IE, все работает как задумывалось. И да — админы домена тоже ничего путного сказать не могут.
1. Перед каждым действием клиенты запрашивают у моего приложения токены сроком действия на 1 час.
2. В каждом запросе на ту или иную операцию клиенты указывают токены.
Запрос пароля организовал так:
1. В JSON-документе заполняются два атрибута username, password, шлется серверу. Пароли хрянятся в PBKDF2 на сервере, в ответ шлется JWT-токен по алгоритму HS256
2. Действие по пункту выше с использованием HTTPS
Но у меня есть вопросы:
1. Почему многие сервисы реализуют регистрацию и доступ через OAuth только для нескольких провайдеров (как правило g+ и fb)? Неужели нет стандарта, который упростит добавление подобных возможностей к себе на сайт «одним кликом»?
2. (вытекает из первого) Почему до сих пор не реализована возможность регистрации и доступа к сервисам через кастомных провайдеров OAuth? Например, у меня есть почта, свой блог, свое «облако» (тот-же ownCloud, например) и я не пользуюсь fb и g+. Я ведь мог бы поднять у себя, на своем домене такого провайдера и в SRV записях прописать свой сервер авторизации(СА). А сайт, на котором я регистрируюсь, исходя из домена, который я указал, ломится на мой СА и получает регистрационные данные с него так, как он это делает в случае с g+? Неужели это никому не нужно?
По #2 — такое предусматривает расширения новейшего стандарта OpenID Connect (http://openid.net/connect/) — посмотрите в секциях Discovery и Dynamic Registrations. Думаю, что в скором времени появятся реализации того, что вы описали, если, конечно, это окажется востребованным.
Было бы здорово если бы существовала единая сервис авторизации который хранил бы в себе все идентификатора человека (пальчики, фото сетчатки, ДНК, обертона голоса....) и у него было бы публичное API. И программисты были бы счастливы и раскрываемость преступлений повысилась бы.
Так есть уже такой сервис, Госуслуги называется. Но помимо вопросов соблюдения конфиденциальности (хотя бы от злоумышленников которые могут получить доступ к их базе данных) есть также еще проблемы с надежностью и производительностью. Если же авторизации через Госуслуги станут делать все кому не лень то оно и вовсе просто ляжет.
Совершенно ясно что такой сервис должен быть как минимум не один (типо на выбор: авторизация через Яндекс, через VK, через Google, по аппаратному ключу, по паролю). Еще лучше была бы вообще распределенная схема авторизации (как DNS, на уровне Интернет-провайдера + можешь выбрать какой-нибудь свой альтернативный, но регистрацией на одном первичном сервисе, с обменом данными между серверами аутентификации, и с возможностью перехода между провайдерами аутентификации), но таких схем, насколько мне известно, пока не придумано. И с учетом того что на практике многие сайты переходят к аутентификации по номеру телефона + SMS/Звонок/Push-уведомления или "2-факторной аутентификации" типа Яндекс-ключа, не похоже что в этом направлении будут какие-то движения.
Ну, HTTP authentication через Digest уязвима не только к MITM-у но и в общем случае и к Relpay-ю. Дело в том что Digest-ы почти всегда не одноразовые и ограничены только сроком действия (обычно у всех это 300 сек.) и на этом как правило все (некоторые реализации хранят все валидные digest-ы но это затратно и от данной атаки все равно не помогает). При этом начинать обмен с запроса digest-а путем посылки неаутентифицированного запроса клиента жестко никто не обязывает и привязки к этапу TCP-соединения тоже нет (а во времена HTTP 1.1 и в принципе быть не могло). Разумеется, попытка это как-то еще закостылить привязкой digest-ов к IP-адресам - вещь сомнительная как в плане удобства пользователей так и в плане того что на этом фоне жесткой проблемой для атаки это все равно не является, поэтому так тоже никто ни в каких библиотеках и ни на каких серверах не делает.
Для эксплуатации этой возможности конечно нужно знать примерно внутреннее устройство сайта (в плане по каким запросам лежат странички с теми формами что вам нужно отправить) и иметь возможность оперативно перехватывать и пускать в дело digest-ы до токо как закончится срок их действия, но если вы, например, админ в какой-то сети то сделать запрос от имени какого-нибудь пользователя который сейчас работает в неком Web-сервисе устроенном по такой схеме для вас вполне возможно и для этого достаточно будет подпатченного Web-браузера (чтобы он уже с первым GET-запросом сразу введенный вами digest использовал) и wireshark-а для перехвата запросов жертвы.
В общем, эту схему можно условно считать безопасной если сервис и все его клиенты находятся в одной условно доверенной (по крайней мере на административном и физическом уровне) локальной сети, но не более того. Она существенно более безопасна (как минимум в плане сложности и возможных масштабов) чем Basic-аутентификация, но для применения в открытых сетях она по хорошему если все равно сама по себе (без SSL) непригодна (а если у вас HTTPS, то преимуществ перед Basic-ом почти и не остается, остуствие возможности кривой реализации с хранением plain text паролей на сервере - это пожалуй полный список всех преимуществ).
Обзор способов и протоколов аутентификации в веб-приложениях