Каков наилучший способ обеспечения многопользовательской безопасности в Breeze?

Я разрабатываю приложение Azure, используя этот стек:

(Клиент) Угловой/Бриз

(Сервер) Веб-API/Breeze Server/Entity Framework/SQL Server

С каждым запросом я хочу убедиться, что у пользователя действительно есть разрешение на выполнение этого действия с использованием кода на стороне сервера. Мой вопрос заключается в том, как лучше всего реализовать это в контексте Breeze/Web API.

Является лучшей стратегией для:

  1. Изменить контроллер веб-API и попытаться проанализировать содержимое запроса Breeze, прежде чем передавать его дальше по цепочке?

  2. Изменить EFContextProvider и добавить проверку авторизации для каждого открытого метода?

  3. Переместить всю безопасность на уровень базы данных и убедиться, что GUID пользователя и GUID арендатора являются обязательными параметрами для каждого запроса и возвращают только соответствующие данные?

  4. Какое-то другое решение или какая-то комбинация вышеперечисленного?


azure entity-framework asp.net-web-api breeze dotnetopenauth
person Graham    schedule 12.10.2013    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Если вы используете Sql Azure, то один из вариантов — использовать Azure Federation, чтобы сделать именно это.

Проще говоря, если у вас есть TenantId в вашей таблице, в которой хранятся данные от нескольких арендаторов, то перед выполнением запроса, такого как SELECT Col1 FROM Table1, вы выполняете инструкцию USE FEDERATION..., чтобы ограничить результаты запроса только определенным TenantId, и вам не нужно добавлять WHERE TenantId=@TenantId к вашему запросу,

Пример ИСПОЛЬЗОВАНИЯ ФЕДЕРАЦИИ: http://msdn.microsoft.com/en-us/library/windowsazure/hh597471.aspx

Обратите внимание, что использование Sql Azure Federation сопряжено с большим количеством связанных строк, когда речь идет о построении схемы БД. Один из лучших блогов, которые я нашел об этом, — http://blogs.msdn.com/b/cbiyikoglu./archive/2011/04/16/schema-constraints-to-consider-with-federations-in-sql-azure.aspx.

person pateketu    schedule 13.10.2013
comment
Это потрясло (в хорошем смысле). Это выглядит превосходно, но, как я читал, я жду какой-то ошибки, например, должен использовать службы управления доступом Azure или работает только с Azure Active Directory! - person Graham; 15.10.2013
comment
Нет таких гочей! просто определенное внимание в схеме БД. В основном 1) Каждая федеративная таблица должна иметь TenantId, и она должна быть частью Parimary key 2) Нет столбцов IDENTITY 3) Нет JOINS с таблицей в корневой БД 3) Таблица справочных данных должна жить в каждой федерации, есть несколько других, которые вы прочитали на. Наше приложение сейчас имеет небольшой размер и нуждается только в одной федерации, мы используем одну и ту же схему для облачной версии и локальной версии приложения. - person pateketu; 15.10.2013