SiteMinder Single-Sign-On без установки агента на сервере веб-приложений

Наш ИТ-персонал отказывается устанавливать агент SiteMinder на веб-сервере нашего приложения IIS 6.0, ссылаясь на соображения безопасности, поскольку это стороннее программное обеспечение, а также на возможность высокого использования ресурсов, влияющего на производительность приложения.

Они предлагают настроить независимый, отдельный веб-сервер, содержащий только базовый IIS, агент SiteMinder и «прокладку» для аутентификации попыток входа в систему.

Эта оболочка представляет собой одну страницу ASPX, помеченную агентом как защищаемую. Он будет использовать агент SiteMinder для аутентификации идентификатора пользователя, поиска идентификатора пользователя в базе данных приложения и возврата идентификатора пользователя и пароля в браузер пользователя. Затем функция JavaScript отправит идентификатор пользователя и пароль на существующую страницу входа в приложение, как если бы они сами ввели их.

Обоснованы ли их опасения? Почему или почему нет?

Вы когда-нибудь слышали о том, чтобы кто-нибудь реализовал подобную архитектуру?

Является ли предложенное ими решение хорошим, плохим или уродливым?


single-sign-on siteminder
person ryandenki    schedule 16.07.2013    source источник

Ответы (2)


arrow_upward
3
arrow_downward

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

В нашей среде весь интернет-трафик проходит через обратный прокси-сервер Apache перед попаданием в IIS. IIS находится за брандмауэром. У обратного прокси-сервера Apache есть агент SM, все, что он делает, это перенаправляет трафик на IIS. Я полагаю, что было бы возможно сделать аналогичную настройку с IIS, выступающим в качестве обратного прокси-сервера.

Кстати, скажите своему ИТ-специалисту, что предложенное им решение для входа в систему с помощью шнурка и жевательной резинки представляет собой гораздо более серьезную проблему безопасности, чем установка SiteMinder на IIS.

person 0leg    schedule 16.07.2013
comment
Я точно знаю? Спасибо за ответ; это именно то непредвзятое мнение третьей стороны, которое мне нужно, хотя я бы хотел, чтобы вы также упомянули о проблемах безопасности, связанных с идеей отправки идентификатора/пароля приложения обратно клиенту. (!!!) В их сценарии сеанс обрабатывается встроенной в приложение аутентификацией по идентификатору/паролю, и SSO знает только об одном защищенном ресурсе: оболочке, которая отправляет пользователю его пароль приложения. шнурок и жевательная резинка, лол. Классический. - person ryandenki; 17.07.2013

arrow_upward
2
arrow_downward

Решение обратного прокси-сервера Apache определенно будет работать, но с SiteMinder r12.51 включен Secure Proxy Server, который в основном представляет собой версию обратного прокси-сервера SiteMinder (плюс многое другое).

SPS позволит вам настроить один сервер в качестве «шлюза» для всех ваших приложений, которые не могут или не хотят устанавливать агент SiteMinder. Веб-агент встроен в SPS, а тяжелую работу выполняет проприетарное приложение Java. SPS также имеет графический интерфейс, который повторяет внешний вид WAMUI r12, что делает его настройку очень простой.

Secure Proxy Server также имеет функцию шлюза федерации, поэтому вам не нужно устанавливать дополнительный пакет веб-агента, если вы используете федерацию SAML. Все ваши страницы fcc также могут обслуживаться SPS, поэтому вы можете уменьшить количество веб-серверов, необходимых для поддержки вашей среды единого входа.

person bcarroll    schedule 13.08.2013