Безопасный только Login.aspx для сайта

Question

1. Можно ли защитить только страницу Login.aspx (и обратную передачу), а не весь сайт в IIS?
2. Мы стремимся сделать это специально с сайтом SharePoint, на котором выполняется проверка подлинности на основе форм для нашей Active Directory.
3. Ссылки на это будут полезны.

Это то, что мы сделали до сих пор:
1. Настройте SharePoint для использования FBA против AD.
2. Перемещена страница входа в Secure / Login.aspx
3. Установите соответствующий URL-адрес для входа в web.config как https://..../Secure/Login.aspx

Это не работает, и здесь нужна помощь. Однако, даже если это работает, как мы можем вернуть пользователя на http с https?

Answer 1

Там не так много смысла. Если единственное, что зашифровано, это страница Login.aspx, это будет означать, что кто-то может прослушивать весь трафик, который не был отправлен через страницу входа.

Что может помешать людям получить пользователя: пройти, но все остальные ваши данные доступны.

Answer 2

Я согласен с AviD и Дэном Уильямсом в том, что защита только страницы входа в систему не является хорошей идеей, поскольку она предоставляет другие данные после ухода со страницы пароля. Однако вы можете требовать SSL только для страницы login.aspx через IIS Manger. Если вы перейдете на страницу login.aspx в IIS Manager (я считаю, что она находится под /_layouts), вы можете щелкнуть правой кнопкой мыши по отдельному файлу и выбрать Properties. Оттуда перейдите на вкладку File Security и нажмите кнопку Edit... под Secure communications. Там вы можете установить флажок Require secure channel (SSL), и SSL потребуется только для этой страницы.

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

Answer 3

Помимо всех данных, которые предоставляются, и действий пользователя, которые могут быть изменены в пути, идентификатор сеанса пользователя (или другие данные аутентификации) отправляются в открытом виде. Это означает, что злоумышленник может украсть ваш файл cookie (...) и выдать себя за вас в системе, даже не получив ваш пароль. (Если я правильно помню, SPSv.3 также поддерживает встроенный модуль смены пароля ...)
Так что я бы сказал, что это не Великая идея, если вы все равно не заботитесь об этой системе ... Но тогда зачем вообще беспокоиться об аутентификации? просто сделать это анонимным?