Самый простой способ реализации аутентификации и авторизации в многоуровневом приложении с WCF и Entity Framework - PullRequest
0 голосов
/ 22 марта 2011

Я разрабатываю (и буду реализовывать) многоуровневое приложение для «управления задачами».
Я хотел бы использовать ASP.NET MVC (не условие) и использовать WCF (любой вид веб-служб) для связимежду сервером и клиентом (= база данных и контроллер в случае MVC).Я хотел бы сделать это с WCF, потому что, вероятно, позже будет настольный клиент (который, вероятно, предоставит только часть функциональности, но все же ...).
Пока у меня есть несколько уровней:

---- Услуги (бизнес-логика) - WCF
--- Репозиторий
- ORM: Entity Framework
- БД: MsSQL

Это должно быть базовым (или давайтескажем сервер) всей системы.Клиент должен быть веб-приложением в ASP.NET MVC или Silverlight, а также настольным приложением (независимо от того, какая технология ... silverlight, формы .. или даже Adobe Flex).

Основные проблемы на данный момент:

  1. Я не знаю, что лучше (проще): Попытка каким-то образом реализовать членство в asp.net по умолчанию и каким-то образом склеить его с моими таблицами для задач (и проектов и т. Д.).Или я должен попытаться изменить членство в asp.net, чтобы использовать мою собственную таблицу пользователей?Мне нужно, чтобы пользователи могли изменять свои данные или создавать нового пользователя и т. Д. Внутри моего приложения (не с помощью инструмента конфигурации ASP.NET).Поэтому я думаю, что мне нужно будет найти простой способ использования членства в asp.net, но с моей таблицей пользователей.

  2. Я не знаю, где и как проводить аутентификацию и авторизацию пользователей.Мне нравится использовать атрибуты на контроллерах, которые говорят, что контроллер недоступен, если пользователь не входит в какую-то группу.Но я думаю, что таким образом я бы защищал только свою клиентскую часть, но сервер остается небезопасным.Поэтому, когда кто-то получает адрес службы, он может позвонить и получить данные.Я не знаю, какой самый простой способ обеспечить безопасность услуг в этом сценарии.Должен ли я добавить дополнительный параметр для каждой операции службы, который предоставит имя пользователя и пароль, которые будут проверять службы каждый раз?Я не думаю, что это правильное решение.

Я действительно застрял с этим .. потому что слишком много разных типов протоколов, сервисов и типов.Я потерян в этом.Также из того, что я видел до сих пор, эта тенденция связана с REST.Что, конечно, круто, и есть отличные шаблоны визуальных студий, такие как WCF Data Service, когда я просто предоставляю свой контекст сущностей, и у меня есть работающее приложение CRUD.Но я не создаю публичную службу, у меня есть одно хранилище с данными для всех пользователей, и каждый пользователь должен видеть только свои данные.

3 - Есть ли простой способ, как генерировать сериализуемые сущности из Entity Framework?Я прочитал несколько параграфов об инструменте «metal», который позволяет сериализовать сущности LINQ to SQL, но я могу их передавать.Я просто хочу узнать, есть ли какой-нибудь способ получше, затем переписать все мои сущности в составные типы (много переназначения).

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

Спасибо за любую возможную подсказку

1 Ответ

0 голосов
/ 23 марта 2011

Мы используем аналогичную архитектуру, но с NHibernate вместо EF.

  1. Поставщик членства ASP.NET предназначен для поддержки сценария, о котором вы говорите.Вы можете создать свой собственный подкласс System.Web.Security.MembershipProvider.Это позволяет вам сопоставить все функции для работы с вашими собственными таблицами.

  2. Вы абсолютно правы - это должно происходить на сервере.Вам нужно заглянуть в System.IdentityModel.Policy.IAuthorizationPolicy.Этот интерфейс позволяет настроить обработку авторизации в службе WCF.Это может быть основано на имени / пароле, аутентификации Windows или даже авторизации на основе утверждений.

  3. Не может помочь с сериализацией EF - но с NHibernate у нас было два варианта: i) Создать DTO для передачина проводе и карте в / из DTO, или ii) Создание пользовательских сериализаторов, чтобы позаботиться о циклических ссылках и т. д. Мы пошли вторым путем.

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

...