Xpoint
   [напомнить пароль]

Такая разная аутентификация

Метки: [без меток]
2007-02-12 12:13:36 [обр] Алексей Шоков(0/9)[досье]

На создание данной темы меня вдохновило обиьное развитие протоколов аутентификации пользователя на веб-сайтах в последнее время. То, что обобщенно называется identity 2.0 практически выливается в такие технологии, как OpneID, TypeKey и CardSpace.

Собственно, технологии хорошие, активно развивающиеся. Разговор не об этом. Разговор о том, что есть на свете и старые добрые средства аутентификации, такие, как банальная проверка имени/пароля пользователя. И это только один пример, средств множетсво.

Почему эти два типа аутентификации разделяются между собой? Мне кажется потому, что в старой системе участие пользователя требовалось только в самом начале: ввести информацию, нужную для данного типа аутентификации. В identity 2.0 (по крайней мере в названных мною технологиях) все не так просто. Участие пользователя требуется и на промежуточных этапах (в OpenID, к примеру, дать согласие провайдеру аутентификации на разрешение исполдьзование учетной записи на конкретном сайте).

Все это влечет к тому, что у меня в голове не нашлось решения закодировать процесс аутентификации с использование какой-либо 2.0 технолгии таким образом (простейший пример использования PHP-библиотеки PEAR::Auth):

require_once "Auth.php";

$options = array(
  'dsn' => "mysql://user:password@localhost/database",
  );
$a = new Auth("DB", $options);

$a->start();

if ($a->checkAuth()) {
    /*
     * Пользователь Аутентифицирован.
     */
}

Т.е. клиент отсылает данный на веб-сайт и получат результат. Клиент в данном случае сделал один запрос. При использовании OpenID, к примеру, одним запросом дело явно не обойдется.

Из сказанного выше я делаю вывод, что технологии аутентификации 2.0 не укладываются в старую схему, следовательно их нельзя приспособить под существующие абстрактные интерфесы аутентификациии. Прав ли я или что-то проглядел? И, если прав, разработаны ли уже какие либо абстрактные интерфейсы для аутентификации 2.0?

спустя 3 часа 53 минуты [обр] Давид Мзареулян(31/1003)[досье]

Алексей Шоков[досье] Зависит от того, что Вы понимаете под «абстрактными интерфейсами». Чем Вам не интерфейс, скажем:

$auth = new Authenticator($authProvider);
if(!$auth->isAuthenticated()) {
    $auth->startAuthenticationProcess();
    return;
}

// Пользователь Аутентифицирован

При этом startAuthenticationProcess() может делать как редирект на страничку ввода логина-пароля, так и инициировать сессию OpenID-авторизации.

спустя 2 часа 47 минут [обр] Алексей Шоков(0/9)[досье]

Давид Мзареулян[досье], вы меня правильно поняли, именно такой интерфейс я бы хотел иметь. Но мне кажется, что такой интерфейс может коректно работать только с аутентификацией, выполняемой за один проход. Если внутри startAuthenticationProcess пользователь будет куда-то перенаправлен, то не известно, бедет ли продолжена процедура выполнения аутентификации (т.е. перейдет ли управление снова к isAuthenticated и далее). К примеру, приведенный вами код запускается только при передаче скрипту параметра doAuth методом POST. Если брать тот же OpenID, то пользователь будет перенаправлен к своему провайдеру аутентификации, а тот в свою очередь перенаправит его обратно на сайт (return_to).

Но управление нужному коду не передастся, т.к. параметр doAuth не передан и не мог быть передан. Как быть в этом случае? Можно, коенчно, заменить метод POST на GET и указать doAuth в параметре return_to. Но мне все таки кажется, что мой пример не надуман.

P.S. Поиск реализации такой абстрактной библиотеки не увенчался успехом, даже про интеграцию протоколов OpenID, TypeKey и CardSpace Google ничего вразумительного не говорит.

спустя 3 минуты [обр] Давид Мзареулян(31/1003)[досье]
Разумеется, в общем случае startAuthenticationProcess вызывает прерывание исполнения текущего скрипта. При проектировании системы именно на это и надо рассчитывать.
спустя 11 минут [обр] Дионис Сантин aka Человек с Ломом(32/406)[досье]
Алексей Шоков[досье]
А если задуматься о прайваси? Например, я не хочу давать вам свой пароль для авторизации на каком-либо авторизационном ресурсе.
спустя 51 минуту [обр] Алексей Шоков(0/9)[досье]

Дионис Сантин aka Человек с Ломом[досье], не понял вас. Авторизация (определение прав аутентифицированного пользователя) не причем, мой вопрос относится именно к аутентификации.

И пароль вы давать кому попало не будете — только своему провайдеру аутентификации, который и поддерживает ваш ауккаунт. В этом и прелесть identity 2.0.

спустя 30 минут [обр] Дионис Сантин aka Человек с Ломом(32/406)[досье]
Алексей Шоков[досье]
Хм. А что тогда вы будете отправлять „провайдеру аутентификации“ в качестве индентификатора меня? )
спустя 1 час 14 минут [обр] Давид Мзареулян(31/1003)[досье]
Дионис Сантин aka Человек с Ломом[досье] Вас самого и будет отправлять:) Вы про OpenID читали?
спустя 14 часов [обр] Дионис Сантин aka Человек с Ломом(32/406)[досье]
сообщение промодерировано
Давид Мзареулян[досье]
Давид, солнце, я про OpenID писал.
Но автору требуется совершенно иное, как я понимаю.
спустя 1 час 53 минуты [обр] Давид Мзареулян(31/1003)[досье]

Дионис Сантин aka Человек с Ломом[досье] «— Вы Камасутру читали? — Я её иллюстрировал!»:)

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

спустя 1 день 20 часов [обр] Сергей Чернышев(39/589)[досье]

Кстати, это правильный момент - разные системы по разному идентифицируют пользователя и если в OpenID пользователь вводит свое имя, то в API того же Facebook-а, например, он просто уходит на другой сайт по ссылке и приходит обратно с session ID.

Думаю, что вопрос privacy имени пользователя тут тоже актуален - я, например, с удовольствием буду пользоваться своим гугловским логином для авторизации, но не буду рад если мой ID (а следовательно и email) будут отданы заправшиваемому сервису.

Powered by POEM™ Engine Copyright © 2002-2005