Аутентификация в многоуровневой архитектуре

Question

Я проектирую систему N-Layer в .NET, которая будет состоять из

• SQL Server 2008
• EF 4
• Слой репозитория
• Сервисный уровень (бизнес-логика)

Кроме того, у меня будет:

• Веб-сайт ASP.NET MVC
• внешний API для использования другими клиентами (построенный с WCF или ServceStack.NET)

Я хотел бы реализовать типичную аутентификацию имени пользователя / пароля в приложении MVC, а также параметры входа OpenID / twitter / facebook

API потребуются аналогичные формы аутентификации.

Где в архитектуре лучшее место для реализации аутентификации, и есть ли примеры того, как реализовать что-то подобное с помощью стека .NET?

Является ли пользовательский поставщик членства вариантом для этого?

Я понимаю, что есть библиотеки, доступные для реализации части openID, так что на данный момент это не проблема, но я бы хотел оставить все как есть, чтобы добавить это в будущем.

Предложения

Answer 1

Аутентификация должна выполняться на стороне пользователя: веб-сайт MVC и служба WCF.

В каждой точке используйте соответствующий механизм аутентификации / авторизации.

Веб-сайт MVC : проверка подлинности на основе форм (или проверка подлинности Windows и т. Д.)

Служба WCF : (какой метод вы будете использовать, ключ API, пароль пользователя / имени при каждом запросе, безопасный ключ, файл cookie авторизации и т. Д.)

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

Сервисный уровень должен возвращать действительный / недействительный для предоставленных ему учетных данных.

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

Если оно действительно , пусть ваш веб-сайт MVC создаст файл cookie авторизации (FormsAuthentication.SetAuthCookie), а ваша служба WCF сделает соответствующее действие для выбранного вами механизма аутентификации.

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

Для входов в систему с открытым идентификатором / Twitter / Facebook вся необходимая информация находится в веб-приложении (через файлы cookie источника входа), поэтому используйте ее для настройки файла cookie для аутентификации вашего сайта.

Answer 2

Как дополнение к ответ Омара :

Вы также можете использовать Facade Pattern , который обрабатывает авторизацию и используется как кодом WCF, так и MVC и предоставляет API для бизнес-уровня.

Практическое правило: поместите авторизацию в одну точку и позвольте клиенту (-ам) обрабатывать логику аутентификации. Не распространяйте его по слою обслуживания!

Answer 3

Извините, пришлось написать это в качестве другого ответа, поскольку в комментариях не хватило места.

Настройте поставщика членства на уровне IIS и используйте поставщик членства OOTB SQL для обеспечения базовой проверки подлинности.

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

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

Answer 4

Базовая архитектура будет заключаться в использовании API членства asp.net для вашего сервиса и веб-приложений, обращающихся в одну базу данных членства.Затем используйте олицетворенного пользователя для подключения к SQL Server.

Затем можно написать пользовательских поставщиков членства для других механизмов аутентификации или объединить их всех в один поставщик членства.