Есть задача — организовать межсайтовую авторизацию между проектами, размещенными на разных доменах (site1.com, site2.com). Пользователь автризовавшись на одном проекте, авторизовывается на всех (Single Sign On). Тоже самое с кнопкой выход (Single Sign Out). Доступ к хранилищу сессий и к базе есть у каждого проекта.
За два дня перелопатил множество статей и обсуждений. Вывод — стандартного решения для моего случая найти не удалось (интранет решения и сайты с четко разделенной открытой/закрытой зоной я не рассматривал).
Update: Продолжение истории Межсайтовая авторизация 2.
Основой этого варианта является централизованный сервер авторизации и HTTP редиректы.
1. Пользователь вводит логин пароль и постит форму.
2. Мы шифруем логин + пароль + урл возврата + урл при неверных логине/пароле + время жизни (не более 30 секунд) c возможность расшифровки и получаем уникальный токен.
3. Делаем редирект на сервер авторизации передавая в параметре полученный токен.
4. Сервер авторизации его расшифровывает и проводит авторизацию.
5. Авторизация прошла: ставим куку, поднимаем сессию и генерируем токен (ид сессии и время жизни токена). Логин/пароль не верный: вместо токена — флаг что авторизация провалилась.
6. Сервер авторизации делает редирект на обратный урл с полученным параметром.
7. Расшифровываем токен и ставим куку.
8. Делаем редирект сами на себя чтобы очистить урл в адресной строке.
1. Пользователь заходит на сайт. Проверяем если ли кука, если есть поднимаем сессию, если нет, то идем дальше.
2. Делаем редирект на сервер авторизации с шифрованным адресом возврата.
3. Сервер авторизации проверяет есть ли кука.
4. Если есть то шифруем токен с ид сессии и временем жизни токена если нет то флаг что куки нету.
5. Делаем редирект обратно с полученным параметром.
6. Расшифровываем токен и ставим куку.
7. Делаем редирект сами на себя чтобы очистить урл в адресной строке.
1. Удаляем куку и шифруем урл возврата.
2. Делаем редирект на сервер авторизаци с урлом возврата и удаляем сессию и куку.
2. Удаляем привязку пользователя к сесии в базе (у меня в таблице users у каждого пользователя сохраняется его текущая сессия, чтобы поднимать ее по куки).
3. Делаем редирект обратно.
Из плюсов хочу заметить что все работает с использованием обычного протокола HTTP без применения дополнительных технологий.
Минус достаточно большой и связан с авторизацией по куки: если у пользователя отключены куки или к нам зашел робот то начинается кошмар: на каждый его запрос будет 3 редиректа + создаваться новая сессия.
Есть 2 варианта решения этой проблемы:
1. Вместо редиректа подключать JavaScript с сервера авторизации, который, если там есть кука, будет поднимать сессию и ставить куку на сайт. Но у этого решения тоже есть минусы: как я понял, есть проблемы с Safari и авторизация по куки не будет работать если отключен JavaScript.
2. Попытаться запалить того кто не сохраняет куки (в основном это роботы). Можно отпарсить XML файл с сайта www.user-agents.org и засунуть его в какой-нибудь MemcacheDb и проверять при каждом запросе. Либо попробовать ставить куку, если не получилось то сохранять IP (можно с User Agent) в том же MemcacheDb и тоже проверять при каждом запросе. Можно комбинировать оба приема.
Особенности этого варианта, что не нужен сервер авторизации и не страшны роботы, а также работает с отключенным JavaScript. Хотя решение честно говоря не самое красивое.
1. Пользователь вводит логин/пароль и постит форму.
2. Авторизуем, ставим куку, поднимаем сессию.
3. Создаем токен: шифруем ид сессии и время жизни токена.
5. Показываем по одной однопиксельной картинке для каждого домена с токеном в урле.
6. Картинки (скрипты которые отдают картинки) расшифровывают токены и ставят куки на каждом домене (не забываем отдавать заголовок P3P:CP=«IDC DSP COR ADM DEVi TAIi PSA PSD IVAi IVDi CONi HIS OUR IND CNT»).
Куки уже стоят на всех доменах.
1. Удаляем куки и сессию.
3. Создаем токен: шифруем ид сессии и время жизни токена.
4. Показываем картинки с каждого домена с токеном в урле.
5. Картинки расшифровывают токен и удаляют куки.
Из минусов: не работает авторизация по куки если отключены картинки. Каждый домен/проект должен знать о всех остальных.
Я сам не выбрал какой вариант использовать, поэтому и решил обсудить эту тему с вами, дабы найти проблемные места и прийти к оптимальному решению.
За два дня перелопатил множество статей и обсуждений. Вывод — стандартного решения для моего случая найти не удалось (интранет решения и сайты с четко разделенной открытой/закрытой зоной я не рассматривал).
Update: Продолжение истории Межсайтовая авторизация 2.
Вариант 1
Основой этого варианта является централизованный сервер авторизации и HTTP редиректы.
Вход:
1. Пользователь вводит логин пароль и постит форму.
2. Мы шифруем логин + пароль + урл возврата + урл при неверных логине/пароле + время жизни (не более 30 секунд) c возможность расшифровки и получаем уникальный токен.
3. Делаем редирект на сервер авторизации передавая в параметре полученный токен.
4. Сервер авторизации его расшифровывает и проводит авторизацию.
5. Авторизация прошла: ставим куку, поднимаем сессию и генерируем токен (ид сессии и время жизни токена). Логин/пароль не верный: вместо токена — флаг что авторизация провалилась.
6. Сервер авторизации делает редирект на обратный урл с полученным параметром.
7. Расшифровываем токен и ставим куку.
8. Делаем редирект сами на себя чтобы очистить урл в адресной строке.
Авторизация по куки
1. Пользователь заходит на сайт. Проверяем если ли кука, если есть поднимаем сессию, если нет, то идем дальше.
2. Делаем редирект на сервер авторизации с шифрованным адресом возврата.
3. Сервер авторизации проверяет есть ли кука.
4. Если есть то шифруем токен с ид сессии и временем жизни токена если нет то флаг что куки нету.
5. Делаем редирект обратно с полученным параметром.
6. Расшифровываем токен и ставим куку.
7. Делаем редирект сами на себя чтобы очистить урл в адресной строке.
Выход
1. Удаляем куку и шифруем урл возврата.
2. Делаем редирект на сервер авторизаци с урлом возврата и удаляем сессию и куку.
2. Удаляем привязку пользователя к сесии в базе (у меня в таблице users у каждого пользователя сохраняется его текущая сессия, чтобы поднимать ее по куки).
3. Делаем редирект обратно.
Из плюсов хочу заметить что все работает с использованием обычного протокола HTTP без применения дополнительных технологий.
Минус достаточно большой и связан с авторизацией по куки: если у пользователя отключены куки или к нам зашел робот то начинается кошмар: на каждый его запрос будет 3 редиректа + создаваться новая сессия.
Есть 2 варианта решения этой проблемы:
1. Вместо редиректа подключать JavaScript с сервера авторизации, который, если там есть кука, будет поднимать сессию и ставить куку на сайт. Но у этого решения тоже есть минусы: как я понял, есть проблемы с Safari и авторизация по куки не будет работать если отключен JavaScript.
2. Попытаться запалить того кто не сохраняет куки (в основном это роботы). Можно отпарсить XML файл с сайта www.user-agents.org и засунуть его в какой-нибудь MemcacheDb и проверять при каждом запросе. Либо попробовать ставить куку, если не получилось то сохранять IP (можно с User Agent) в том же MemcacheDb и тоже проверять при каждом запросе. Можно комбинировать оба приема.
Вариант 2
Особенности этого варианта, что не нужен сервер авторизации и не страшны роботы, а также работает с отключенным JavaScript. Хотя решение честно говоря не самое красивое.
Вход
1. Пользователь вводит логин/пароль и постит форму.
2. Авторизуем, ставим куку, поднимаем сессию.
3. Создаем токен: шифруем ид сессии и время жизни токена.
5. Показываем по одной однопиксельной картинке для каждого домена с токеном в урле.
6. Картинки (скрипты которые отдают картинки) расшифровывают токены и ставят куки на каждом домене (не забываем отдавать заголовок P3P:CP=«IDC DSP COR ADM DEVi TAIi PSA PSD IVAi IVDi CONi HIS OUR IND CNT»).
Авторизация по куки
Куки уже стоят на всех доменах.
Выход
1. Удаляем куки и сессию.
3. Создаем токен: шифруем ид сессии и время жизни токена.
4. Показываем картинки с каждого домена с токеном в урле.
5. Картинки расшифровывают токен и удаляют куки.
Из минусов: не работает авторизация по куки если отключены картинки. Каждый домен/проект должен знать о всех остальных.
Я сам не выбрал какой вариант использовать, поэтому и решил обсудить эту тему с вами, дабы найти проблемные места и прийти к оптимальному решению.
