SSO между ASP.NET, ASP и PHP

Question

Я работаю над сайтом, который является ядром / мастером ряда сайтов. Мы также несем ответственность за проверку подлинности на всех сайтах под баннером бренда.

Клиент хотел включить операцию единого входа, поэтому, если бы я должен был войти на любой из сайтов, я бы вошел на все сайты. Мы обрабатываем дочерние входы на сайт путем перенаправления на основной сайт (наш) и выполнения входа в систему.

Было решено, что SSO будет работать посредством встраивания тегов изображений в страницу и последующего вызова страницы на каждом дочернем сайте. Это откроет сеанс клиента для их сайта, чтобы они могли устанавливать cookie-файлы / делать то, что они хотят обработать для входа в систему.

Это работает по большей части , оно было протестировано на IE7, FF 2 & 3, и все они работают. Проблемным браузером на данный момент является Safari (и Chrome). Хотя изображения, по-видимому, загружаются в сеансе клиента, похоже, не открываются, мы не получаем куки с набора дочерних сайтов. Похоже, проблема в браузерах на основе WebKit, в которых проблемы с Safari и Chrome (я бы предположил, что konqueror может постигнуть та же участь, но в данный момент у меня нет установки Linux в моем распоряжении).

Кто-нибудь знает, как Safari распознает встроенный тег изображения на внешнем хосте как открытие клиентского контекста? Или кто-то может предоставить лучший способ сделать единый вход из ASP.NET для сайтов, которые не являются ASP.NET?

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

Answer 1

Большая часть работы с SSO, с которой я работал, использует централизованный сервер аутентификации ( CAS ) и работает с билетами, передаваемыми через параметры запроса и куки.

Основная идея заключается в том, что если ваш сайт не обнаруживает тикет, он перенаправляется на ваш веб-сайт CAS. Веб-сайт выполняет аутентификацию, устанавливает файл cookie для аутентификации и перенаправляет обратно на ваш сайт с уникальным одноразовым билетом (в качестве параметра запроса). При перенаправлении ваш сайт обнаруживает билет и выполняет обратный вызов на сервер CAS, чтобы выкупить билет с помощью внеполосного веб-запроса. Этот запрос возвращает идентификатор пользователя, который вошел в систему. Это используется для установки аутентифицированного пользователя в вашем приложении.

Сервер CAS отслеживает, каким приложениям разрешено SSO друг с другом. Когда запрос на аутентификацию поступает с сайта в пуле единого входа и билет аутентификации соответствует другому сайту в пуле, сервер САПР отвечает билетом без принудительной повторной аутентификации. Таким образом, ваши сайты могут просто ссылаться друг на друга без какой-либо особой «магии», просто в зависимости от того, что cookie CAS сделает так, чтобы пользователь мог обойти повторную аутентификацию между связанными сайтами.

Answer 2

Это похоже на Safari (по крайней мере, на моей OS X - который должен быть настройками по умолчанию) и, я предполагаю, что Chrome не разрешает сторонние куки по умолчанию .

Safari-> Настройки-> Безопасность-> Принять Cookies:

o Всегда
o Никогда
+ Только с сайтов, по которым вы переходите

Существует несколько AJAX-хакеров для получения вашего домена документов для установки cookie, но я не думаю, что это действительно решит вашу проблему здесь. Я думаю, что Safari даже запрещает iframes устанавливать сторонние cookie, если, возможно, вы не установили document.domain (хотя, если вы использовали общий домен, вы могли бы просто установить домен cookie и покончить со всем этим).

Если не считать window.open или серии переадресаций, я не могу придумать, что вы можете сделать, чтобы обойти проблему со сторонними файлами cookie - так что я бы, вероятно, отказался от уловки встроенного изображения и начал бы с нуля.