Реализация Single Sigon для сайтов ASP.NET и Classic ASP

Question

У нас есть два старых сайта в классическом ASP и несколько сайтов в ASP.NET 2.0. Наша новая разработка также относится к ASP.NET, и постепенно мы можем переместить наши классические ASP-сайты в .NET. Все эти сайты используют одну и ту же внутреннюю базу данных.

На данный момент мы планируем перенести нашу аутентификацию пользователей на один сервер и начать использовать единый вход (SSO). Я не могу решить, что будет лучшим или правильным способом. Наши веб-сайты asp.net используют FormsAutentication с CustomMembership и RolesProvider, т.е. мы используем наши пользовательские таблицы вместо таблиц по умолчанию aspnet_membership.

Пути, которые я могу думать:

1: Использовать Веб-сервис : Я могу переместить код аутентификации на веб-сервис, и все наши сайты могут его использовать. Но я не уверен, как единый вход подходит для сайтов ClassicASP.

2: я слышал о DotNetOpenAuth : наши внешние пользователи создаются нашим внутренним персоналом. Они могут войти в систему только используя предоставленные нами имя пользователя и пароль. Поэтому они не могут войти в систему с помощью Google, Yahoo или любого другого имени пользователя / пароля. Поэтому я не уверен, подходит ли DotNetOpenAuth в нашем случае. Я видел пример SSO при загрузке DotNetOpenAuth, но понятия не имею, с чего начать.

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

Answer 1

Что ж, возможно, вам подойдет один из пассивных протоколов единой регистрации. Вы можете выбрать между WS-Federation, SAML или Shibboleth, но первое, WS-Federation, легко поддерживается в .NET с подсистемой Windows Indentity Foundation.

Способ работы WS-Federation заключается в том, что вы экстернализуете аутентификацию / авторизацию для отдельного веб-приложения (так называемая служба маркеров безопасности ). Каждое из федеративных клиентских приложений (так называемых проверяющих сторон ) полагается на информацию, предоставляемую службой.

Основные потоки управления таковы:

1. клиент указывает свой браузер на RP-приложение
2. браузер перенаправляет (302) на STS
3. если STS был посещен и пользователь уже вошел в STS, перейдите к 5.
4. STS показывает страницу входа и проверяет пользователя
5. STS возвращает браузеру страницу, содержащую подписанный токен XML со всей информацией об аутентификации, а также крошечный javascript для перенаправления в приложение RP
6. приложение RP выбирает токен и создает собственную аутентификацию на основе предоставленной информации

WIF предоставляет вам инструменты для простой сборки STS и RP, а интеграция с унаследованными приложениями также проста - вы можете либо приложить усилия для обработки протокола на уровне унаследованных приложений, либо предоставить «brige», приложение .NET, использующее WIF, который использует STS и передает информацию об аутентификации в устаревшее приложение.

Замечательно также то, что с WIF вы все еще придерживаетесь старых, хороших понятий, таких как проверка подлинности с помощью форм и поставщики членства - это может быть предпочтительным выбором реализации STS.

Сам протокол WS-Federation не только обеспечивает единый вход, но и позволяет легко обрабатывать единый вход (который не поддерживается некоторыми другими протоколами, такими как openid).

Подробнее о теме в этой книге:

http://www.amazon.com/Programming-Windows-Identity-Foundation-Dev/dp/0735627185

Answer 2

Оформить заказ это руководство на "Претензии на основе идентификации и контроля доступа". глава 3 , в частности: «Единый вход на основе утверждений для Интернета и Windows Azure» (Azure не требуется).

Это хорошо объясняет современный подход Microsoft реализации стратегии единого входа.

Кроме того, эта статья TechNet очень помогла нам начать работу с WIF и ADFS 2.0.