Comments 20
Подскажите пожалуйста, а LDAP/AD аутентификация в данной классификации где находится? Интересует такой вариант SSO, когда веб-приложение аутентифицирует пользователя по его системному логину без ввода какой-либо дополнительной информации в веб приложении.
Аутентификация по паролю -> HTTP authentication -> Kerberos (схема Negotiate).
В этом случае пользователю не придется дополнительно что-либо вводить для аутентификации: браузер автоматически аутентифицируется используя Kerberos тикет, полученный от AD при логине в Windows (по сути это вариант аутентификации по токену). На стороне веб-приложения мы сможем получить информацию о доменном аккаунте аутентифицированного пользователя.
В этом случае пользователю не придется дополнительно что-либо вводить для аутентификации: браузер автоматически аутентифицируется используя Kerberos тикет, полученный от AD при логине в Windows (по сути это вариант аутентификации по токену). На стороне веб-приложения мы сможем получить информацию о доменном аккаунте аутентифицированного пользователя.
Спасибо!
LDAP-аутентификация и AD-аутентификация — это совершенно разные вещи. LDAP-аутентификация — это когда веб-приложение принимает от пользователя логин с паролем и проверяйет их по LADP-базе. Этот примитивный способ, в котором SSO и не пахнет, тем не менее, часто выдается за полноценную аутентификацию в AD.
AD-аутентификация — да, она реализуется через схему Negotiate. Но у нее есть недостатки — к примеру, нормально работать с этой схемой может только IE — остальным браузерам понадобится другой способ аутентификации и никакого SSO в итоге не случится.
Поэтому если нужно сделать SSO — надо использовать WS-Federation или OpenID-connect, а уже на стороне Identity Provider можно применить Negotiate как один из вариантов внутренней аутентификации.
AD-аутентификация — да, она реализуется через схему Negotiate. Но у нее есть недостатки — к примеру, нормально работать с этой схемой может только IE — остальным браузерам понадобится другой способ аутентификации и никакого SSO в итоге не случится.
Поэтому если нужно сделать SSO — надо использовать WS-Federation или OpenID-connect, а уже на стороне Identity Provider можно применить Negotiate как один из вариантов внутренней аутентификации.
ну почему, Гугл Хром нормально работает с NTLM(AD) авторизацией.
Используем в паре проектов — вы не представляете, насколько ниже нагрузка на сопровождающих:
нет ввода пароля — нет его «забывания» и неправильного ввода, блокировок и заявок на разблокировку…
Если пользователь вошёл в домен — значит может и работать в программе.
Один момент только портит всю картину — иногда по непонятным причинам (при заливке и скачиваниии файла) у пользователя IE идёт запрос пароля. Админы домена не могут ничего путного сказать…
Используем в паре проектов — вы не представляете, насколько ниже нагрузка на сопровождающих:
нет ввода пароля — нет его «забывания» и неправильного ввода, блокировок и заявок на разблокировку…
Если пользователь вошёл в домен — значит может и работать в программе.
Один момент только портит всю картину — иногда по непонятным причинам (при заливке и скачиваниии файла) у пользователя IE идёт запрос пароля. Админы домена не могут ничего путного сказать…
А я вот, приходя на работу, вынужден логиниться сразу аж в трех рабочих сайтах. Сначала пытался изображать из себя крутого безопасника, набирая один и тот же пароль в 4х окнах подряд — но потом устал и запомнил его в браузере.
При этом у тех, кто переносит IE, все работает как задумывалось. И да — админы домена тоже ничего путного сказать не могут.
При этом у тех, кто переносит IE, все работает как задумывалось. И да — админы домена тоже ничего путного сказать не могут.
Крутое покрытие темы, спасибо!
В прошлом году делал Identity Provider на основе протокола OpenID Connect — очень понравилось. В протоколе есть и аутентификация и авторизация и механизм передачи данных о пользователе от провайдера потребителю. Делалась возможность авторизовывать пользователя на подчинённых сайтах через учётную запись главного сайта, подчинённые сайты получали только те данные, на которые они попросили разрешения (и пользователь одобрил), эти же разрешения позволяли подчинённым сайтам взаимодействовать с API основного сайта от имени пользователя (была возможность засылать уведомления пользователю в личный кабинет). В общем, почти так же круто, как у фейсбука. Самым же весёлым было то, что пользователь на основном сайте мог зарегистрироваться через социальные сети и в результате получалась цепочка из Identity Provider — Service Provider. Использовал гем с внезапным названием openid_connect.
Authentication — Authorization — Accounting: вот стандартная триада управления доступами (AAA), про Identification не уверен.
Однозначно в «избранное».
Великолепный материал. Хабр — торт!
DataArt: А что на Ваш взгляд подходит для RESTful приложений?
Зависит от конкретной ситуации, но если нужно аутентифицировать пользователей в RESTful APIs, то логичнее всего будет использовать токены. Как я уже писал, в этом случае клиент (мобильное приложение, браузерное JavaScript приложение или серверное приложение) должно предварительно получить токен от сервера аутентификации. Посмотрите пример архитектуры вот тут: identityserver.github.io/Documentation/docs/overview/bigPicture.html
DataArt: Я сделал так:
1. Перед каждым действием клиенты запрашивают у моего приложения токены сроком действия на 1 час.
2. В каждом запросе на ту или иную операцию клиенты указывают токены.
Запрос пароля организовал так:
1. В JSON-документе заполняются два атрибута username, password, шлется серверу. Пароли хрянятся в PBKDF2 на сервере, в ответ шлется JWT-токен по алгоритму HS256
2. Действие по пункту выше с использованием HTTPS
1. Перед каждым действием клиенты запрашивают у моего приложения токены сроком действия на 1 час.
2. В каждом запросе на ту или иную операцию клиенты указывают токены.
Запрос пароля организовал так:
1. В JSON-документе заполняются два атрибута username, password, шлется серверу. Пароли хрянятся в PBKDF2 на сервере, в ответ шлется JWT-токен по алгоритму HS256
2. Действие по пункту выше с использованием HTTPS
Благодарю за материал, очень познавательно, закинул в мемориз ;)
Но у меня есть вопросы:
1. Почему многие сервисы реализуют регистрацию и доступ через OAuth только для нескольких провайдеров (как правило g+ и fb)? Неужели нет стандарта, который упростит добавление подобных возможностей к себе на сайт «одним кликом»?
2. (вытекает из первого) Почему до сих пор не реализована возможность регистрации и доступа к сервисам через кастомных провайдеров OAuth? Например, у меня есть почта, свой блог, свое «облако» (тот-же ownCloud, например) и я не пользуюсь fb и g+. Я ведь мог бы поднять у себя, на своем домене такого провайдера и в SRV записях прописать свой сервер авторизации(СА). А сайт, на котором я регистрируюсь, исходя из домена, который я указал, ломится на мой СА и получает регистрационные данные с него так, как он это делает в случае с g+? Неужели это никому не нужно?
Но у меня есть вопросы:
1. Почему многие сервисы реализуют регистрацию и доступ через OAuth только для нескольких провайдеров (как правило g+ и fb)? Неужели нет стандарта, который упростит добавление подобных возможностей к себе на сайт «одним кликом»?
2. (вытекает из первого) Почему до сих пор не реализована возможность регистрации и доступа к сервисам через кастомных провайдеров OAuth? Например, у меня есть почта, свой блог, свое «облако» (тот-же ownCloud, например) и я не пользуюсь fb и g+. Я ведь мог бы поднять у себя, на своем домене такого провайдера и в SRV записях прописать свой сервер авторизации(СА). А сайт, на котором я регистрируюсь, исходя из домена, который я указал, ломится на мой СА и получает регистрационные данные с него так, как он это делает в случае с g+? Неужели это никому не нужно?
Спасибо. По #1 — для добавления поддержки нового провайдера требуется зарегистрировать сервис у этого провайдера (получить ключи доступа) и реализовать механизм псевдо-аутентификации (вызовы API этого провайдера). Плюс управление учетными записями пользователей (например, слияние аккаунтов из разных провайдеров). В целом, это несложный процесс, и для многих языков программирования существуют пакеты, которые это упрощают. Но автоматического добавления нового провайдера по одному клику стандарт OAuth не поддерживает.
По #2 — такое предусматривает расширения новейшего стандарта OpenID Connect (http://openid.net/connect/) — посмотрите в секциях Discovery и Dynamic Registrations. Думаю, что в скором времени появятся реализации того, что вы описали, если, конечно, это окажется востребованным.
По #2 — такое предусматривает расширения новейшего стандарта OpenID Connect (http://openid.net/connect/) — посмотрите в секциях Discovery и Dynamic Registrations. Думаю, что в скором времени появятся реализации того, что вы описали, если, конечно, это окажется востребованным.
Мы сейчас используем связку rest + cas + ldap. Cas единожды настраивается на LDAP, потом все клиенты стучаться в кас за аутентификцией или запрашивают тикеты для других приложений, таким образом реализован доступ к рест сервису по тикетам и SSO между приложениями
Было бы здорово если бы существовала единая сервис авторизации который хранил бы в себе все идентификатора человека (пальчики, фото сетчатки, ДНК, обертона голоса....) и у него было бы публичное API. И программисты были бы счастливы и раскрываемость преступлений повысилась бы.
Sign up to leave a comment.
Обзор способов и протоколов аутентификации в веб-приложениях